What logging and monitoring should a small production app have?

Short answer: you want to know when the app is down, when errors happen, and enough context to debug them. Start small with three layers: uptime checks, error tracking and structured logs.

1. Uptime monitoring

An external service pings your site (and a health endpoint) every minute or so and alerts you by email, chat or SMS. Also monitor the TLS certificate expiry and the domain renewal.

A good health endpoint checks dependencies, for example a quick database query, and returns a non-200 status on failure.

2. Error tracking

Capture unhandled exceptions with stack traces, the request, the user id (not sensitive data) and the release version. Group duplicates and alert on new errors. Add the same for front-end errors.

3. Application logs

• Write logs to stdout or a file and rotate them so the disk does not fill.
• Use levels (debug, info, warning, error) and set production to info or higher.
• Prefer structured logs (JSON) with fields such as request id, user id and duration, so they are searchable.
• Never log passwords, tokens, full card details or personal data you do not need.
• Add a request id and pass it through to make tracing a request easy.

4. Basic metrics

CPU, memory, disk, response times and error rates; queue length and failed jobs if you use background workers.

5. Alerts that people trust

Alert on symptoms that need action (site down, error rate spike, disk nearly full, backups failed), and send them to a channel that someone actually watches. Too many noisy alerts get ignored.

Pitfalls

• Logging everything at debug level in production.
• No retention policy, so costs or disk usage grow.
• Not testing that alerts reach a human.

Review incidents afterwards and add the monitor that would have caught the issue sooner.