---
title: Incident Management & Timelines
description: Incidents that open only on confirmed failures, with root cause, confirming checks, a full timeline, team notes, post-mortems and maintenance windows.
canonical: https://watchfor.io/incident-management
---

# Incident Management That Starts With a Confirmed Failure

An alert that might be noise gets ignored. A WatchFor incident opens only once the failure is confirmed from several locations, with the evidence attached.

[Get started for free](/auth/sign-up)[View pricing](/pricing)

## What Every Incident Comes With

From the first failed check to the post-mortem, on one page

### Confirmed Before Anyone Is Paged

A failed check marks the monitor Degraded and starts faster re-checks from its locations. An incident opens only when the confirmation threshold is met: three consecutive failures by default, adjustable from 1 to 10 per monitor. A failure that stops reproducing never becomes an incident.

### Firing, Acknowledged, Resolved

Any member can acknowledge, which stops reminders, repeat notifications and the escalation chain. The incident keeps counting as downtime until it resolves, either on recovery (three consecutive successful checks; one for domain expiry, certificate, breach and blocklist checks, whose answers do not flap) or when an owner or admin resolves it.

### Full Timeline

First detection, each confirming check counting toward the threshold (1/3, 2/3, 3/3), the moment it was confirmed, the acknowledgement, escalation steps, every notification with its channel and outcome, and the resolution. All in your profile's time zone and 12- or 24-hour format.

### Root Cause and the Rule That Fired

What visitors experienced, the locations that confirmed the failure and any that still saw the target fine, and expected vs. detected values. Then the likely causes and copy-paste commands (dig, curl -I, openssl s_client, mtr) with your host filled in. The panel judges the incident against the rule version in effect when it fired.

### Private Internal Notes

A team-only thread on the incident page. @mention a teammate and they get the note by email, pin the finding that matters, react with 👀 or ✅ instead of replying. Notes never appear on a status page or in notifications. A plan feature, not included on Free.

### Post-Mortems You Can Publish

Start a post-mortem from the incident: a templated write-up, your severity assessment, a root-cause category, your own timeline entries and action items with assignees and due dates. Owners and admins can publish a completed post-mortem to the incident's status page.

### Resolve, or Mark as False Positive

Owners and admins resolve by hand when a fix was verified out of band; a still-failing condition re-opens the incident. An incident that was real to the checks but not to your users can be marked a false positive. It stays on record but leaves uptime, SLA, reports and the status page.

### Grouping & Noise Control

When ten monitors fail together, chat and email channels get one summary per channel instead of ten messages. The first window is about 30 seconds, so a lone incident still arrives promptly with full detail. A critical incident holds back warnings on the same monitor, and a flapping monitor stops notifying until it settles.

## An incident from first failure to post-mortem

A certificate 30 days from expiry: Degraded, a warning, uptime still 100%.

The 2 s warning closed when the 3 s critical level took over.

Firing, acknowledged and resolved incidents from every monitor type.

Acknowledge or resolve several firing incidents at once.

Confirmed, notified on three channels, acknowledged, then resolved.

Every notification for the incident, by channel, status and time.

The confirmed incident posted itself on the public status page.

A post-mortem with severity, root cause, impact and what changes next.

## Why Manage Incidents in WatchFor?

Monitoring and incident handling usually live in separate tools, joined by a webhook and a lot of copy-paste. In WatchFor the incident is opened by the same checks that saw the failure, so it already knows which locations confirmed it, what the rule expected and what came back. While it is open, most check types run faster than their normal interval, so recovery shows up within a minute or two rather than at the next scheduled check. Maintenance windows silence planned work without stopping the checks, and acknowledgements, resolves and notes are recorded in the activity log.

[Start monitoring now](/auth/sign-up)

Incidents open only at the confirmation threshold (3 failed checks by default)

Any member can acknowledge; owners and admins resolve

Acknowledging stops reminders and the escalation chain

Root cause shows expected vs. detected and the rule version that fired

Faster checks while an incident is open, so recovery is seen within minutes

One summary per channel when many monitors fail at once

Maintenance windows silence alerts and keep planned work out of uptime

False positives stay on record but leave uptime, reports and the status page

## How Incident Management Works

From a failed check to a written post-mortem

1

### A Failure Is Confirmed

A check fails, the monitor turns Degraded and is re-checked on an accelerated schedule. When the threshold is met, the incident opens and your contact groups' channels are notified; a critical incident also starts the escalation policy, if you have one.

2

### Someone Acknowledges

Whoever takes it clicks Acknowledge on the incident page, from the incidents list or over the API. Reminders and escalation stop, and the timeline records who took it.

3

### The Team Investigates

Read the root cause and the confirming checks, run the suggested commands and coordinate in internal notes. If the monitor is on a status page, the incident is published there and you add customer updates.

4

### It Resolves, You Write It Up

It resolves itself after three consecutive successful checks (one for domain expiry, certificate, breach and blocklist checks), or an owner or admin resolves it. The channels that were alerted get the recovery and the reason. Then start the post-mortem from the incident page.

## Incident Management Use Cases

Where confirmed incidents change the work

### On-Call Response

Only confirmed critical incidents start an escalation, so the person paged at night is paged for something real. Acknowledging stops the chain, and the timeline shows who took it and when.

### Team Coordination

Debugging happens in internal notes; the customer summary goes on the status page. Notes never reach the public page, its feed or your notifications.

### Blameless Post-Mortems

The timeline, the confirming checks and the rule version in effect give the write-up facts instead of memories. Action items with owners and due dates keep follow-ups from being forgotten after the meeting.

### Cutting Alert Fatigue

Confirmation filters out one-path blips, grouping turns a storm into one message per channel, and flapping monitors go quiet until they settle. Fewer incidents, and each one is worth opening.

## Frequently asked questions

How incidents open, close and get recorded

[All questions→](/faq)[Ask us directly](/contact)

When does an incident open? After the failure is confirmed. A failed check marks the monitor Degraded, and WatchFor re-checks on an accelerated schedule, rotating through the monitor's locations, until the confirmation threshold is met: three consecutive failed checks by default, adjustable from 1 to 10 per monitor. Only then does an incident open. Down means a confirmed critical incident is open; Degraded means a check failed and nothing is confirmed yet, or a warning incident is open.

What is the incident lifecycle?

What's included in an incident's root cause?

What are internal notes?

Can I resolve an incident manually or mark it a false positive?

Can I write a post-mortem?

How does WatchFor reduce alert noise?

How do incidents relate to my status page?

Is everything that happens recorded?

What happens to incidents during maintenance?

## From our blog

Guides, deep-dives, and best practices from the WatchFor team

[Reliability

### Maintenance windows done right: stop paging yourself for planned work

Aug 23, 2026·5 min readRead article](/blog/maintenance-windows-done-right)[Reliability

### Incident Response: a step-by-step playbook

Apr 29, 2026·3 min readRead article](/blog/incident-response-playbook)[Reliability

### Incident Severity Levels (SEV1–SEV4) Explained

Nov 20, 2025·3 min readRead article](/blog/incident-severity-levels)

## Get Incidents Worth Opening

Add a monitor and its default alert rules are already on, routed to your default contact group. The next confirmed failure opens an incident with its root cause and confirming checks. Start on the Free plan, no credit card required.

[Get started for free](/auth/sign-up)[View documentation](/docs/alerting/incidents)

---

Canonical page: https://watchfor.io/incident-management · Site guide: https://watchfor.io/llms.txt
