The Startup Guide to Incident Response: What to Set Up Before Your First Outage

You Will Have an Outage

Every startup ships fast. That's the point — speed is your competitive advantage. But shipping fast means cutting corners on infrastructure, deferring monitoring, and hoping that your MVP holds together long enough to find product-market fit.

Then one day your app goes down. Maybe it's a database migration that locks a table. Maybe it's a third-party API that stops responding. Maybe it's a null pointer exception in a code path nobody tested.

The outage itself isn't the problem. How your team responds to it is. And if you haven't set anything up before it happens, you'll spend the first 30 minutes of the outage figuring out the process instead of fixing the issue.

Here's what to set up before your first outage. It takes about an hour.

The Four Things Every Startup Needs

You don't need a 50-page incident response playbook. You don't need a dedicated SRE team. You don't need enterprise monitoring with 500 dashboards. You need four things:

1. Monitoring — Know when something breaks before your users tell you
2. On-call — Know who's responsible for responding right now — and whether that person is actually available, not on a beach
3. Notifications — Reach the responsible person reliably
4. Tracking — Record what happened so you learn from it

That's it. These four capabilities cover 90% of incident response for teams under 50 people.

Step 1: Monitoring (15 Minutes)

Start with heartbeat monitoring for your most critical services. You can add application performance monitoring, log analysis, and distributed tracing later. Right now, you need to know when something stops running.

Heartbeat monitoring inverts the usual model: instead of an external service polling your endpoints, your service (or a small cron job) sends a POST request to a unique ping URL on a fixed interval. If the pings stop arriving — after a grace period and a failure threshold you configure — an alert fires. This catches a class of failures that outbound polling misses entirely: the cron that silently stopped running, the worker that hung, the box that lost network. If your process can't ping, something is wrong, whatever the cause.

What to monitor first:

Four monitors. That's your starting point. Each one is a POST to its ping URL — a one-line curl in a cron, or an SDK call from inside the service loop.

Configuration recommendations for startups:

• Interval: 60 seconds. That's also the minimum — pinging more often than once a minute doesn't buy you faster detection.
• Failure threshold: 3 consecutive missed pings (prevents false positives from transient issues)
• Grace period: 60 seconds (prevents alert flapping during deployments and restarts)

For anything revenue-critical like payments, don't shorten the interval below 60 seconds — instead, ping from the code path that actually processes payments, so the monitor reflects the thing you care about rather than a proxy for it.

You can add more monitors as you identify critical paths. But these four will catch the outages that matter most.

Step 2: On-Call (10 Minutes)

If your team is 2-5 engineers, your on-call setup is simple: a rotation where everyone takes turns being the primary responder.

For a 3-person team:

• Weekly rotation: Alice (week 1) → Bob (week 2) → Charlie (week 3) → repeat
• Handoff time: Monday 10 AM (gives the incoming on-call time to settle in)
• Backup: The next person in the rotation is the secondary

For a 2-person team:

• Weekly rotation: Alice (week 1) → Bob (week 2) → repeat
• Backup: The other co-founder/engineer
• Consider: Alternating 3-4 day shifts instead of full weeks to prevent burnout

For a solo founder:

• You're always on-call (sorry)
• Set up monitoring and notifications so you know about issues fast
• When you hire your first engineer, set up a rotation immediately

Turn on PTO conflict detection from day one. The most common on-call failure at small companies isn't a bad rotation — it's a correct rotation pointing at someone who's on vacation. On a 3-person team, one person taking a week off breaks a third of your schedule, and nobody notices until an alert goes unanswered. OpShift's Red Sign checks your on-call schedule against logged PTO and flags the conflict before it becomes a missed page. It's on the free tier, so there's no reason to defer it: log time off in the same tool as the rotation, and conflicts surface automatically.

The important thing isn't the rotation structure — it's that at any given moment, one specific person knows they're responsible and is actually reachable. "Everyone is on-call" means nobody is on-call. So does "the on-call is in Portugal."

Step 3: Notifications (15 Minutes)

You need a notification setup that reaches an engineer at their desk without waking the whole team, and still gets through at 3 AM when it matters.

The mechanism for this is two-sided:

• Escalation steps define what happens when an alert fires: which channels (Slack DM, SMS, phone call), who gets them (the on-call, or the whole team), and how long to wait before the next step.
• Per-user quiet hours let each engineer set do-not-disturb windows in their own account settings — so a low-stakes overnight Slack DM doesn't buzz their phone.
• For alerts that must get through regardless, mark an escalation step bypass quiet hours. That step delivers even inside someone's DND window.

Don't overcomplicate this. At an early stage, two escalation steps are enough:

1. Notify the primary on-call via Slack DM immediately, plus SMS
2. If no acknowledgment in 5-10 minutes, phone-call the primary and notify the secondary

Then have each engineer set their own quiet hours for the channels they don't want overnight, and mark the second step to bypass quiet hours — that's your wake-me-up-at-3-AM path. This gets you time-appropriate delivery without maintaining separate "business hours" and "after hours" configurations.

You can add severity-based escalation rules and more channels as your team grows. Right now, you need a reliable way to reach one person.

Step 4: Tracking (20 Minutes)

When an incident is resolved, you need a record of what happened. This doesn't need to be elaborate — you just need enough information to learn from the experience.

At minimum, track:

• What went wrong (1-2 sentences)
• When it started and when it was resolved
• What fixed it
• What you'll do to prevent it next time (1-2 action items)

Use your incident management tool's built-in tracking rather than a separate document. When the alert is in the same system as the tracking, you get an automatic timeline of detection, acknowledgment, and resolution.

The One-Hour Setup Guide

Here's the complete sequence, assuming you're starting from zero:

Minutes 0-5: Create your account and team Sign up for an incident management platform. Create your team and invite your co-founder or engineers.

Minutes 5-15: Set up monitors Create heartbeat monitors for your 3-4 critical services and wire up the pings — a cron line or an SDK call per service. Use the recommended configurations above.

Minutes 15-25: Configure on-call rotation and PTO Create a weekly rotation with your team. Set the handoff time to a morning slot during business hours. Log any upcoming time off so schedule conflicts get flagged immediately.

Minutes 25-40: Set up notifications Connect Slack. Add phone numbers for SMS and phone calls. Configure a two-step escalation: primary on-call, then secondary. Have each engineer set their quiet hours, and mark the escalation step that should get through anyway.

Minutes 40-50: Test the setup Trigger a test alert (stop one of your pings) and verify it reaches the on-call engineer through the correct channels. Verify the escalation path works by not acknowledging the test alert and confirming the secondary gets notified.

Minutes 50-60: Document the basics Write a short message in your team Slack channel: who's on-call this week, what the escalation path is, and how to acknowledge alerts. This is your incident response documentation for now.

When to Add Complexity

Your one-hour setup will serve you well for months. Here's when to add more:

When you hit 5-10 engineers: Add severity levels to your alerts. Not every monitor failure is critical — start differentiating between "app is completely down" and "one endpoint is slow," and give each severity its own escalation steps.

Once Slack is connected: Add Slack channel listeners to catch issues reported by team members before monitoring detects them.

When you have your first repeat incident: Set up a simple post-mortem process. Attach a root cause analysis to the incident and track the action items.

When you have 10+ monitors: Add webhook integrations from your other tools (error tracking, CI/CD, custom scripts) to centralize alerts.

When you have a distributed team: Add timezone-aware scheduling and consider follow-the-sun rotations.

When alert volume increases: Add alert grouping and webhook filtering to reduce noise.

When you hit 15+ engineers: Split into per-service or per-team rotations so nobody is on-call for systems they don't own.

What Not to Do

Common mistakes startups make with incident response:

Don't skip monitoring because "we'll just watch the logs." You won't. And when something breaks at 2 AM, nobody is watching anything.

Don't use a shared on-call phone. It gets left on someone's desk. Use a rotation with individual phone numbers.

Don't build your own alerting. A cron job that checks your endpoint and posts to Slack is not incident response. It has no escalation, no acknowledgment tracking, no history — and worst of all, it fails silently: when the cron itself dies, you get no Slack message and no signal that anything is wrong. Keep the check script if you like it, but point it at a heartbeat monitor so a dead script becomes an alert instead of silence.

Don't wait until after your first major outage. The worst time to set up incident response is during an incident. It takes an hour now or several hours during a crisis.

Don't over-engineer it. You don't need runbooks for every possible failure mode. You need to know when something breaks and how to reach the person who can fix it.

Start Simple, Scale Later

OpShift is designed for teams that want to start simple and add complexity as they grow. The initial setup takes minutes: add monitors, create a rotation, configure notifications. As your team grows, add Slack listeners, webhook integrations, alert grouping, and multi-channel escalation.

Pricing is per team, not per seat, and every tier includes up to 100 team members — adding your PM, your support lead, and your CTO costs nothing extra. The Developer tier is free and covers the planning half of this guide: on-call scheduling, PTO tracking, and Red Sign conflict detection (no monitors or alerting). Basic is $16/month and adds up to 100 monitors with 100 message credits for SMS and phone delivery; Pro is $39/month with 2,500 message credits for teams with higher alert volume. Get started at opshift.io.