Production Monitoring Setup

Set up monitoring for a production application. If a target is provided, scope recommendations to that service or feature. Cover all four pillars, then configure health checks, alerts, SLOs, and dashboards.

The Four Pillars

Monitor all four. Missing any one creates a blind spot.

1. Errors

Track unhandled exceptions, failed API calls, and client-side errors. Don't wait for users to report them.

Tool examples: Sentry (full stack, source maps, release tracking), LogRocket (session replay + error context).

2. Performance

Measure response times and user experience. Use percentiles, not averages.

Tool examples: Vercel Analytics (zero-config for Next.js), Speedlify (self-hosted Lighthouse tracking).

3. Availability

Know when your service is down before your users do.

Tool examples: Better Uptime (status pages + incident management), Checkly (synthetic monitoring with Playwright).

4. Business Metrics

Technical metrics alone don't tell you if the product works.

Tool examples: PostHog (open-source product analytics, feature flags, session replay), Mixpanel (funnel and retention analysis).

Health Check Endpoint

Create a /api/health endpoint that verifies real connectivity, not just "the server is running."

// app/api/health/route.ts
import { NextResponse } from 'next/server'

export async function GET() {
  const checks: Record<string, 'ok' | 'fail'> = {}

  // Check database connectivity
  try {
    await db.query('SELECT 1')
    checks.database = 'ok'
  } catch {
    checks.database = 'fail'
  }

  // Check external services (cache, queue, etc.)
  try {
    await redis.ping()
    checks.cache = 'ok'
  } catch {
    checks.cache = 'fail'
  }

  const allHealthy = Object.values(checks).every((s) => s === 'ok')

  return NextResponse.json(
    { status: allHealthy ? 'healthy' : 'degraded', checks },
    { status: allHealthy ? 200 : 503 },
  )
}

Adapt the checks to the actual services in the stack. Return 503 if any check fails so load balancers and uptime monitors detect it.

Alerting Strategy

Alert on actionable signals only. Noisy alerts get ignored.

Rules for good alerting:

• Don't alert on single transient errors. Use thresholds and windows (e.g., "error rate > 5% over 5 minutes").
• Every alert must have a clear owner and a documented first-response action.
• Review alert fatigue monthly. If an alert fires > 3 times without action, fix it or remove it.

SLOs (Service Level Objectives)

Define SLOs for key services. SLOs set expectations; SLIs measure them.

How to use error budgets:

• When the budget is healthy, ship fast and take calculated risks.
• When the budget is low, freeze non-critical deploys and focus on reliability.
• Track budget burn rate weekly. A sudden spike means something broke.

Dashboard Essentials

Build a team dashboard with these panels. Keep it to one screen.

Incident Response

Use severity levels to set expectations and escalation.

For every incident:

1. Acknowledge the alert and declare severity.
2. Open an incident channel (or thread) for coordination.
3. Mitigate first, investigate second. Get the service back up, then find root cause.
4. Write a brief post-incident review: what happened, why, and what will prevent recurrence.