How to Handle Production Incidents When You're a Team of One

The solo incident problem

At a large company, incidents are handled by teams: someone on-call escalates, engineers coordinate, communications go out. As a solo founder, you're the on-call, the engineer, and the communications team simultaneously.

Step 1: Assess scope in 2 minutes

Before doing anything: how many users are affected? What functionality is broken? Is it getting worse? Check your error dashboard for frequency and user count. This determines urgency.

Step 2: Communicate before you fix

If paying users are affected, send a brief status update before you even start debugging. "We're investigating an issue with X, will update in 30 minutes." Users are far more forgiving when they're informed.

Step 3: Use your tools intelligently

Open ProdFix → find the top error → copy to Cursor or read via MCP → ask Claude to diagnose and fix. Don't debug from scratch — let your monitoring tool give you the context and your AI tool write the fix.

Step 4: Deploy and watch

After deploying the fix, watch your error dashboard for 10 minutes to confirm the error rate drops. Don't close the incident until you see the numbers improve.

Step 5: Write a brief post-mortem

Even for small incidents, write three sentences: what broke, why it broke, what you changed to prevent it. This helps you notice patterns and prevents the same bugs recurring.

The preparation that prevents 80% of incidents

Most incidents are preventable. Error monitoring catches bugs before they become incidents. Monitoring before launch, alerts configured, MCP connected — this is your on-call rotation.