Incident Response Playbook: Detection to Post-Mortem

Do You Have a Plan for When a Client Site Goes Down?

When a client's website stops responding, every minute matters. Without a documented response process, teams waste time figuring out who should do what instead of fixing the problem. Worse, delayed client communication compounds the damage.

This guide walks through a 5-step incident response framework: Detect, Assess, Communicate, Recover, and Report.

Step 1: Detect -- Catch the Problem Immediately

Manual checking does not scale. If you manage more than a handful of client sites, automated monitoring is non-negotiable.

Miterl monitors your sites continuously and sends alerts through Slack, email, or webhooks the moment something fails.

Alert contacts (notification destinations) are created in the dashboard and attached to each monitor. When you create a monitor via the API, pass the contact IDs returned by GET /alert-contacts in the alert_contact_ids field.

# List your alert contacts and their IDs
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {id, type, name}'

Pass those IDs as alert_contact_ids when creating a monitor to wire up down/recovery notifications. With a 60-second interval_seconds, Miterl detects outages within a minute. The faster you know, the faster you respond.

The most fundamental layer of detection is HTTP response monitoring — checking the status code returned on every request. For how to design alerts by status code (4xx vs 5xx), see "HTTP Response Monitoring: Detect Failures by Status Code."

Step 2: Assess -- Understand the Scope

When an alert fires, resist the urge to start fixing things immediately. Take 2-3 minutes to assess the situation first.

Run through this checklist:

[ ] Which site(s) are affected?
[ ] What type of failure? (HTTP error, SSL, DNS, timeout)
[ ] Were any recent changes deployed?
[ ] Is the issue isolated or affecting multiple clients?
[ ] Assign an incident owner

Check Miterl's dashboard for the affected monitor's status history and response logs. This data helps you narrow down root cause quickly rather than guessing.

Step 3: Communicate -- Inform the Client Within 15 Minutes

Send the first client notification within 15 minutes of detection, even if you do not yet know the cause. Silence is worse than incomplete information.

Your first message should cover three points:

• You are aware of the issue
• Investigation is underway
• When the next update will be sent

Template:

We have detected an issue affecting your website and are currently investigating. We will provide an update within 30 minutes.

If you use status pages, update the status to "Investigating" immediately. This reduces inbound inquiries while you focus on resolution.

When the First Alert Goes Unacknowledged

Step 3 assumes someone sees the alert and sends that first client notification. But what if the primary on-call is asleep, driving, or out of signal when the alert fires? A single Slack notification is not a plan. Escalation design closes this gap: if there is no acknowledgment within a set window, the alert automatically advances to the next person or the next channel. For an agency managing multiple client sites, this staged approach is what keeps you within SLA when the situation is least convenient. For a detailed guide to building these escalation rules — who, when, and which channel — see "Monitoring Alert Escalation for Agencies: Who and When."

Step 4: Recover -- Fix the Problem

Apply the appropriate fix based on the failure type. Here are the most common patterns:

Continue sending client updates every 30 minutes during extended outages. Each update should state what you have tried and what you are doing next.

Step 5: Report -- Write the Post-Mortem

Within 24 hours of recovery, produce an incident report. This document serves two purposes: it reassures the client that you take reliability seriously, and it gives your team a reference to prevent recurrence.

Include these sections:

1. Timeline: When the incident started, was detected, and was resolved
2. Impact: Which sites and features were affected
3. Root cause: What went wrong, explained clearly
4. Response log: Chronological list of actions taken
5. Prevention: Specific steps to avoid a repeat (e.g., add SSL expiry monitoring, increase server capacity)

Building the Playbook Into Your Team

A response plan only works if everyone knows it exists. Take these steps:

• Store the playbook in a shared location (wiki, Notion, or repo)
• Assign on-call rotations with clear escalation paths
• Run a tabletop drill quarterly to keep the process fresh
• Review post-mortems as a team to internalize lessons

To feed your internal tools or Slack bots, you can pull the current open incidents from Miterl's API and surface them where your team works:

# List ongoing (unresolved) incidents to drive your own tooling
curl -s "https://miterl.com/api/v1/incidents?status=ongoing" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {id, monitor_id, severity, cause, started_at, is_acknowledged}'

Summary

Incident response is preparation, not improvisation. A documented playbook reduces mean time to recovery and protects client trust during the moments that matter most. Miterl's automated detection and multi-channel alerting handle the first critical step so your team can jump straight to action.

One side effect of improving your detection coverage is alert fatigue: when false positives and planned-maintenance notifications pile up alongside real incidents, engineers start tuning out. That erodes the fast first-response this playbook is designed to deliver. Before you scale monitoring across more client sites, see "Preventing Alert Fatigue in Website Monitoring" for a practical guide to quiet hours, maintenance windows, and confirmation settings that keep every incoming alert actionable.

Once you have a response process in place, Step 5 becomes much faster with a ready-made template. "Incident Report Template for Web Agencies" provides a copy-paste-ready post-mortem format you can hand directly to clients, covering timeline, root cause, and prevention steps. For the email copy that bookends the report — initial outage alert, mid-incident progress update, and recovery confirmation — see "Downtime Notification Email Templates."

Explore the documentation to configure alerting, test your setup by signing up for free, and read more operational guides on the blog. To automate incident detection and trigger auto-recovery workflows, see "Webhook Integration for Uptime Monitoring." Before a new site goes live, the "Pre-Launch Monitoring Checklist" ensures all eight monitoring items are in place from day one. A common blind spot during incidents is broken mail authentication — if your client's SPF or DMARC record is misconfigured, incident notification emails and post-mortem reports may land in spam. "Setting Up and Continuously Monitoring SPF, DMARC, DKIM, and MX Records" covers how to verify and monitor these records as part of your response readiness.

The speed of your first response depends entirely on how quickly the monitoring system catches the problem. Configuring HTTP response time thresholds, status code checks, and alert triggers so that an outage registers within the first minute — rather than after several retries — compresses the whole incident timeline. "Response Time Monitoring Guide: Detecting HTTP Response Failures Early" covers the concrete configuration steps for making your detection layer as fast as possible.