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.

From first failed check to recovery

Uptime keeps raw evidence separate from confirmed customer impact.

Visual guide

Check fails

Evidence

Failure repeats

Threshold

Regions agree

Confirmed

Team notified

Response

Checks recover

Resolved

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

The first five minutes

Open the incident

Use the alert link or choose Incidents. Confirm the affected monitor, start time, current state, and failing regions.

The queue starts with Open incidents. Filter by status or search monitor names and incident summaries. Each row separates the failure, assignee, acknowledgment, and duration. Open an incident from its monitor name; the Incidents breadcrumb returns to your filtered page.

Acknowledge it

Acknowledgment tells teammates that someone has seen the incident. Choose an Assignee to make ownership explicit. Acknowledgment does not mark the service healthy and does not stop monitoring.

Verify customer impact

Try the customer action, inspect the failed checks, compare regions, and check related monitors. Describe what users cannot do—not only which server failed.

Check recent changes

Look for deployments, configuration changes, provider events, expired certificates, DNS changes, or scheduled work near the incident start.

Send a useful update

If customers are affected, publish a brief status-page update with the impact and next update time.

Read the timeline

The detail page has three sections:

  • Activity shows the newest events first. Filter lifecycle events, internal notes, or public updates, or switch to oldest first. Choose Add internal note to record work visible only to your team.
  • Evidence shows failure classification, searchable regional checks, and overlapping maintenance. Checks are grouped and paginated; they describe recorded incident evidence rather than current probe health.
  • Communications shows public updates, status-page destinations, and notification delivery. A failed-delivery count helps you spot communication problems even when another section is open.

The freshness indicator shows when the incident was fetched. A refresh failure keeps the last successful snapshot visible with a warning. Workspace viewers can inspect incident history; response controls are available to members with update permission.

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

In Communications, write the update and choose Review public update. Review the exact message and each status page's publication and access settings, then choose Publish update. Internal notes use a separate editor in Activity.

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

Choose Resolve, enter a resolution summary, and submit. Closing a confirmed outage can queue recovery notifications according to workspace settings. Failed saves keep your draft and dialog open so you can retry. You can edit the post-incident summary after resolution. Reopen returns the incident to investigating and resets acknowledgment and its previous resolution summary.

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.