Monitoring, logs and alerts

Why monitor?

Most users do not report problems. They see an error, close the tab and do not come back. Monitoring means machines watch the app all the time and tell a person when something is wrong, often before many users notice.

A health endpoint

A health endpoint is a small route, such as GET /api/health, that says whether the app can do its job. It checks the parts it depends on, mainly the database, and returns 200 when all is well or 503 (Service Unavailable) when something is broken.

app.get('/api/health', async (req, res) => {
  const checks = {};
  try {
    await db.query('SELECT 1'); // a tiny query: can we reach the database?
    checks.database = 'ok';
  } catch (err) {
    checks.database = 'fail';
  }
  const healthy = Object.values(checks).every((v) => v === 'ok');
  res.set('Cache-Control', 'no-store');
  res.status(healthy ? 200 : 503).json({ status: healthy ? 'ok' : 'error', checks });
});

An uptime monitor is an outside service, such as UptimeRobot or Better Stack, that calls your health URL every minute or few minutes from several places. If it fails, it alerts you by email, SMS or a phone app. Many platforms can also use the health path to restart an unhealthy instance. Free plans exist, but their limits change; check the official pages.

Logs that help, without leaking

A log is a line your app writes for each event. Structured logs are written as JSON with fixed field names, one line per event, so a log tool can search and count them ("all requests with status 500 in the last hour"). For Express, a fast JSON logger such as pino is common. Add a request id to every line, so you can follow one request through all its log lines.

{"level":"info","time":"2026-10-19T08:15:02.120Z","requestId":"9f1c2a","method":"POST","path":"/api/notes","status":201,"durationMs":48,"userId":17}

Errors and the key numbers

Error tracking tools such as Sentry catch crashes in the browser and on the server, group the same error together, and show the stack trace (the list of function calls that led to it), the release and how many users were hit. You fix the biggest group first.

Why p95 and not the average? An average hides the slow requests. If 19 requests take 50 ms and one takes 5 seconds, the average is about 300 ms and looks fine, but one user in twenty waited 5 seconds. The p95 shows that pain.

Alerts, backups and incidents

• An alert must reach a person who can act: a phone notification or SMS to whoever is on duty, not only an email folder nobody opens.
• Alert on what users feel: the site is down, or the error rate is above 2% for 5 minutes. Too many small alerts teach people to ignore all of them.
• Backups: managed PostgreSQL usually has automatic backups and point-in-time recovery (restoring the database to how it was at a chosen minute). Check how many days your plan keeps.
• Test the restore: once a month, restore a backup into a new, separate database and check the notes are there. Note how long it took.

1. Acknowledge the alert and tell the team you are on it.
2. Look at what changed: the last deploy, config, traffic, the provider's status page.
3. Stop the harm first: roll back, restart or switch the feature off.
4. Tell users in plain words (a status page or a banner) if they are affected.
5. Fix the cause, then write a short, blameless note: what happened, why, and what will stop it happening again.