What Should a Startup Log? A Practical Logging Plan

Log at boundaries and at decisions. These categories cover most needs:

• Requests: one line per inbound request with method, route template, status and duration.
• Errors: every unhandled exception with a stack trace and the context needed to reproduce.
• Background jobs: start, finish, failure and retry count for each job, with its identifier.
• External calls: which third-party service was called, how long it took and whether it failed.
• Security and audit events: sign-ins, failures, permission changes, data exports and administrative actions.
• Business milestones: signup completed, payment succeeded, subscription changed. These help support and debugging.

Skip the play-by-play inside functions. If a line wouldn't help someone at 2 a.m., it's noise, and noise makes the useful lines harder to find.

Use structured logging, meaning one JSON object per line, rather than free text. That lets you filter by field instead of writing regular expressions. Standardize these fields across every service:

• A timestamp in UTC and a severity level.
• Service name, environment and deployed version.
• A request or trace ID that follows the request across services.
• A tenant or account ID, and a user ID that is an internal identifier, not an email.
• The event name as a stable, searchable string, plus a short message.
• Error type and message when relevant.

The request ID is the single most valuable field. With it, you can pull every line from one failing request across every service in a few seconds. Add it in middleware once, so nobody has to remember. If you version your API, include the version too; it pairs well with the versioning policy outline.

Logs get copied to vendors, shared in chat and read by many people, so treat them as widely exposed. Never write:

• Passwords, API keys, session tokens or authorization headers.
• Full payment card numbers or bank details.
• Full request and response bodies by default, which often contain personal data.
• Personal data that isn't needed to debug, such as full names, addresses or health information.

Add a redaction layer in your logger that masks known sensitive keys, and write a test for it. Review what your framework logs by default, since some log query strings and headers. If a customer requests deletion of their data, logs are part of the picture, which is why minimizing personal data in logs saves you work later.

Use levels consistently. ERROR means a person should look at this, WARN means something unexpected but handled, INFO covers normal milestones and DEBUG is off in production unless you're actively investigating. If everything is ERROR, nothing is.

Then tier your retention:

1. Searchable, short-term: errors and warnings for a couple of weeks, where fast queries matter.
2. Sampled: routine request lines, sampled or aggregated once you have volume.
3. Archive: everything else in low-cost storage for as long as you need it, retrievable when required.
4. Audit logs: kept separately, with retention set by your compliance obligations, and protected from edits.

Check current pricing for your logging vendor, because ingestion and indexing are often billed separately. Trimming an observability bill is a separate exercise from deciding what to log, so settle the plan first. The platform comparison covers vendor differences.

Run a drill. Pick a recent bug or pretend one, and try to answer: which customer was affected, which request failed, what did each service do and what changed recently? If you can trace it in five minutes using only logs, the plan works. If you need to guess or add new log lines and redeploy, note exactly what was missing and add it.

Review the plan quarterly along with cost. Remove lines nobody has queried, add fields that keep being needed and confirm that redaction still holds after code changes.