Logging and Monitoring for Small Apps: Know Before Your Users Do

Most small apps have no monitoring at all until the day a user emails "is the site down?" That's a rough way to find out. The good news: you don't need an observability team or an expensive platform. A few well-chosen practices give you most of the value, and many of the tools have free tiers.

The four things worth having

1. Logs: what happened, in detail.
2. Error tracking: which exceptions occurred, how often, with stack traces.
3. Uptime checks: is the site reachable from the outside?
4. Metrics: numbers over time, like response times, error rates and resource usage.

Add alerts on top of those so that problems reach you instead of waiting to be discovered.

Logging that helps

Use structured logs

Plain text logs are easy to write and painful to search. Structured logs (JSON) are easy to filter, aggregate and query:

// Hard to search
console.log('User 42 failed to pay order 991: card declined')

// Easy to search and filter
logger.warn({ event: 'payment_failed', userId: 42, orderId: 991, reason: 'card_declined' })

Libraries like pino (Node.js), structlog (Python) and Monolog (PHP) make this simple.

Use log levels consistently

• error: something failed and needs attention.
• warn: something unexpected, but the app coped.
• info: important business events: signups, payments, deploys.
• debug: detail for development, usually off in production.

Add a request ID

Generate an ID for each request, include it in every log line from that request, and return it in a response header. When a user reports a problem, one ID finds every related log line across services.

Never log secrets or sensitive data

No passwords, tokens, API keys, full card numbers or unnecessary personal data. Logs get copied, shipped to third parties and kept for a long time. Redact at the logger level so nobody has to remember. (Security checklist.)

Rotate and retain

Logs fill disks, and full disks crash apps. Use log rotation on servers, and decide how long to keep logs (often 7 to 30 days for app logs).

Error tracking

An error tracker like Sentry (with a free developer plan) or similar tools captures exceptions with stack traces, the request, the user, the browser and recent events leading up to the error. It groups duplicates and tells you when a new kind of error appears after a deploy.

This is the single highest-value monitoring tool for most apps. Upload source maps so frontend stack traces point to your real code. (Reading stack traces.)

Uptime monitoring

An external service requests your site every minute or few minutes, from outside your infrastructure, and alerts you when it fails. Check:

• Your homepage
• A health endpoint that verifies the app can reach its database
• Certificate expiry (HTTPS guide)

app.get('/health', async (req, res) => {
  try {
    await db.query('SELECT 1')
    res.json({ status: 'ok' })
  } catch {
    res.status(503).json({ status: 'degraded' })
  }
})

Metrics that matter

You don't need hundreds of dashboards. For a web app, start with the RED metrics per endpoint:

• Rate: requests per second.
• Errors: percentage of failed requests (5xx).
• Duration: response time, especially the slow tail (95th or 99th percentile), not just the average.

Plus a few resource metrics for servers: CPU, memory, disk space and database connections.

Averages hide pain. If your average response is 200ms but 5% of requests take 8 seconds, a lot of users are having a bad time. (Diagnosing slowness.)

Alerts that are worth it

Bad alerting is worse than none. If alerts fire constantly, people learn to ignore them, including the one that matters.

• Alert on symptoms users feel: site down, error rate spike, checkout failing, very slow responses.
• Don't alert on everything that's unusual. High CPU for two minutes isn't an emergency if users are fine.
• Make each alert actionable. If nobody would do anything about it, it's a dashboard item, not an alert.
• Route by urgency: critical issues to your phone, everything else to email or chat.

A starter setup for a small app

Need	Simple option
Structured logs	A JSON logger, shipped to your host's log viewer or a log service
Errors	Sentry or a similar error tracker
Uptime	An external uptime monitor checking /health
Metrics	Your host's built-in metrics, or a free APM tier
Alerts	Uptime + error tracker alerts to email and phone

That takes an afternoon to set up and covers the vast majority of incidents.

FAQ

What should I log in a web application?

Errors with context, important business events like signups and payments, and request summaries with IDs and timings. Avoid secrets, passwords, tokens and unnecessary personal data.

What is the difference between logging and monitoring?

Logs record detailed events for investigation. Monitoring watches metrics and health checks over time and alerts you when something goes wrong.

What are the RED metrics?

Rate (requests per second), Errors (failed requests) and Duration (response times). They're a simple, effective way to monitor any request-driven service.