What to Log When You Are the Only One Reading It

The 2am Question

When you are the only one reading the logs, structured logging nodejs becomes less about human readability and more about machine queryability. You need fields that answer specific questions instantly, without you having to parse free-form text while half-asleep.

On a single VPS running a shared PostgreSQL 16 database for both the Next.js application and Instalaz, every process competes for the same 12GB of RAM. If a log line is vague, you cannot correlate it with database latency or memory pressure quickly. The goal is to make the log entry a snapshot of state, not a narrative of events.

Fields Over Prose

Prose logs fail at scale because they force the reader to extract data. Instead, use a consistent JSON schema. Every entry should include a unique request ID, a timestamp with millisecond precision, and a severity level that matches your alerting thresholds.

For the Next.js process serving four sites via host-based routing, include the hostname in every log line. This allows you to filter traffic from pracandy.com versus flix.pracandy.com immediately. If you are debugging a slow response, you need to know which site generated the request before you look at the stack trace.

Include the user ID or session token, but never log sensitive data like passwords or payment details. The log should tell you who was affected, not what they did. This distinction keeps the logs useful for debugging while maintaining privacy compliance.

Correlating Processes

Instalaz runs as a separate Node process on port 3050, proxied by Caddy. Because it shares the database with the main application, a slow query in one can starve the other. Structured logs allow you to trace a request from the Caddy proxy through the Node process and into the database layer.

Use a common trace ID across these boundaries. When a scheduled task runs via a systemd oneshot service, it should inject this ID into its logs. This lets you see if a background job is holding a database lock that is blocking user requests. Without this correlation, you are guessing at the cause of latency.

Static sites like GamingCap and Invoiceful do not generate server logs, but their impact is visible in Caddy’s access logs. Ensure your Caddy configuration logs the upstream response time. This tells you if the delay is in the static file serving or in the shared infrastructure.

Reading the Data

At 2am, you are not reading logs; you are filtering them. A command like grep "error" app.log | tail -n 20 is useless if the error message is a string of human-readable text. Structured logs let you filter by field: jq 'select(.level == "error")'.

Keep the log volume manageable. On a 193GB disk, excessive logging can fill the drive and crash the system. Rotate logs daily and compress old entries. Use systemd timers for this rotation, not cron, to ensure it runs reliably alongside other scheduled work.

The value of structured logging is not in the writing, but in the querying. If you cannot answer a question in two commands, the log format is wrong. Design the schema for the questions you expect to ask in the middle of the night, not the ones you think are interesting during the day. For more on managing independent web properties, see the PracandyFlix publication for insights on building small-scale digital products.