Respond to an incident

What an incident means

An incident is created when monitor evidence reaches the failure policy you configured. It is more meaningful than one failed check because repeated failures and regional agreement may be required first.

Uptime records the exact lifecycle so your team can separate detection, confirmation, response, communication, and recovery.

The first five minutes

Read the timeline

The incident detail page is a chronological record. It can include:

• the first observed failure;
• regional threshold changes;
• incident confirmation;
• notification attempts and outcomes;
• acknowledgment;
• team or public updates;
• recovered checks;
• final resolution.

Use the timeline as the shared source of truth. Avoid splitting important facts across private chat messages that future responders cannot see.

Describe impact clearly

Prefer customer language:

• “Some customers cannot complete checkout.”
• “Sign-in requests are taking longer than normal in Europe.”
• “New exports are delayed; existing reports remain available.”

Avoid announcing a total outage when one region or capability is affected. Also avoid dismissing a regional failure when customers in that geography are genuinely affected.

Write the first public update

A helpful investigating update contains four parts:

1. the customer-visible symptom;
2. affected components or regions;
3. what the team is doing;
4. when the next update will arrive.

Example:

We are investigating increased errors when customers submit checkout in North America. Product browsing remains available. Our team is reviewing the payment request path, and we will provide another update within 30 minutes.

Do not include private hostnames, credentials, unconfirmed causes, or internal blame.

Continue updates

Use predictable stages:

• Investigating — impact is confirmed and the cause is still being studied;
• Identified — the team has identified the likely cause and is applying a fix;
• Monitoring — the fix is in place and evidence is being watched;
• Resolved — the recovery policy is satisfied and normal service is confirmed.

If there is no major change, still tell customers what is being checked and when they can expect the next update.

Confirm recovery

One successful check may be a temporary improvement. Uptime waits for the configured recovery threshold before resolving the incident.

Before closing your response:

• confirm multiple regions are healthy;
• repeat the affected customer action;
• check that response time returned to a normal range;
• confirm queued or delayed work is recovering;
• verify the resolved notification was delivered;
• publish a customer-facing resolution.

After resolution

Capture what will reduce future impact:

• What first indicated the problem?
• Was the alert early, late, or noisy?
• Did the monitor represent the customer action accurately?
• Were the correct people notified?
• Was the status page easy to update?
• Should a new monitor, runbook, or maintenance process be added?

The goal is not to assign blame. It is to improve detection, response, and customer communication.

If the incident appears false

Inspect the failed observations before labeling it a false positive. The cause may be an overly strict timeout, a changing keyword, a blocked region, or a real local outage.

Resolve the configuration cause, then adjust the monitor carefully. Do not delete incident history; it explains why the policy changed.

See Troubleshoot a failed check and Design an alert policy for the next steps.