> ## Documentation Index > Fetch the complete documentation index at: https://pulse-41cf5b0d.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Incident Management and Post-Mortems > Track outages through a full lifecycle from Investigating to Resolved. Attach post-mortems with root cause analysis, timelines, and action items. When PulseGuard confirms that a monitor has gone DOWN, it automatically creates an **incident** — a structured record that tracks the outage from first detection through to resolution. Incidents give your team a shared, authoritative source of truth during an outage, a timeline of all events and status updates, and a permanent audit trail you can reference after the fact. Every status page subscriber watching an affected monitor also receives email updates tied to the incident lifecycle. ## What Incidents Are An incident is more than a log entry. It is a collaborative workspace attached to one or more affected monitors that your team can update in real time as an outage unfolds. Each incident has a severity level, an ordered timeline of events, a current status drawn from the standard lifecycle, and an optional post-mortem document for after the dust settles. PulseGuard creates incidents automatically when monitors go DOWN. You manage the status progression and add context manually through the dashboard, keeping your status page subscribers and teammates informed without leaving PulseGuard. ## Incident Lifecycle Every incident moves through four standardized statuses. Each transition is recorded as an immutable audit event, giving you a precise timeline of how the incident evolved. PulseGuard creates the incident and sets it to **Investigating** the moment a monitor's DOWN status is confirmed. This is the starting state — your team knows something is wrong but has not yet identified the cause. Status page subscribers receive an initial notification that the team is looking into reported issues. Move the incident to **Identified** once your team has pinpointed the root cause. Update the incident with a brief description of what is causing the outage. This status communicates to subscribers and stakeholders that the problem is understood, even if a fix is not yet deployed. Transition to **Monitoring** after you have applied a fix or mitigation and are watching the monitor to confirm stability. This signals that the immediate crisis is over but you have not yet declared full recovery. Subscribers see that the situation is improving. Mark the incident **Resolved** once the monitor is confirmed UP and stable. PulseGuard records the resolution timestamp, calculates the total incident duration, and notifies status page subscribers that the service has recovered. You can then attach a post-mortem to the closed incident. PulseGuard also **auto-resolves** an incident when the associated monitor recovers and no further failures occur. The auto-resolve event is logged in the incident timeline with the message "Monitor recovered. Auto-resolving incident." You can still add a post-mortem and additional notes to an auto-resolved incident. ## Flapping and Incident Re-Opening If a monitor recovers and then fails again within a short window, PulseGuard detects the instability as **flapping** and re-opens the existing incident rather than creating a new one. The incident timeline receives a "Monitor unstable — incident re-opened (Flapping detected)" entry, and the status resets to **Investigating**. This prevents your incident list from accumulating dozens of duplicate records during a chaotic recovery and keeps the full history of an unstable event in one place. ## Managing an Incident from the Dashboard Navigate to **Dashboard → Incidents** to see all active and recent incidents. Click an incident to open its detail view. You will see the affected monitor, current status, severity, and the full event timeline. The incident detail page lists every monitor linked to the incident. For each affected monitor you can see its current status, the region where the failure was first detected, and a link to the monitor's check history. Click **Add Update** to post a new entry to the incident timeline. Use updates to share investigation progress, describe what changed, or note that a fix is being deployed. Each update is timestamped and attributed to your account. Use the **Status** dropdown to move the incident through its lifecycle — from **Investigating** → **Identified** → **Monitoring** → **Resolved**. Each status change is recorded automatically as a `STATE_CHANGE` event in the timeline. When the outage is over, set the status to **Resolved** and add a closing update summarizing what happened. PulseGuard records the resolution timestamp and notifies status page subscribers of the recovery. ## Regional Incidents A monitor checked from 50+ geographic locations can experience a failure that is geographically isolated — for example, your API might be unreachable from US-East but fully healthy everywhere else. PulseGuard tracks these as **regional incidents** alongside the top-level incident, so a localized US outage does not mask the global picture. Each regional incident records: * The affected monitor * The specific region where the failure was detected * A start timestamp and, once resolved, an end timestamp Regional incidents resolve independently. When a region recovers, its regional incident closes automatically without affecting the top-level incident — which stays open until all regions are healthy or you resolve it manually. This granularity lets your team communicate clearly about partial degradation ("US-East is experiencing issues; all other regions are operating normally") rather than reporting a blanket global outage. Created when failures are detected across multiple regions or when the primary check fails regardless of region. Tracked at the monitor level and surfaced on your status page. Created per-region when only specific geographic locations report failures. Resolved independently as each region recovers, keeping your global health view accurate. ## Post-Mortems After resolving an incident, attach a **post-mortem** document to capture institutional knowledge about the outage and prevent recurrence. Post-mortems are stored permanently alongside the incident and are accessible to your entire team. A PulseGuard post-mortem contains the following sections: A concise, plain-language description of what happened, who was affected, and for how long. A chronological account of the incident, cross-referenced with the automated timeline entries PulseGuard recorded during the outage. The underlying technical or process failure that caused the incident. Be specific — vague root causes produce vague action items. Concrete, assignable follow-up tasks that reduce the likelihood or impact of a similar incident. Each item should have a clear owner and a target completion date. A classification of the incident's impact: `HIGH`, `MEDIUM`, or `LOW`. Severity is set when the incident is created (PulseGuard defaults new incidents to `HIGH`) and can be adjusted in the post-mortem. **How to attach a post-mortem:** Navigate to **Dashboard → Incidents**, filter by **Resolved**, and click the incident you want to document. Click **Write Post-Mortem**. The editor opens with section prompts for Summary, Timeline, Root Cause, and Action Items. Complete all sections thoroughly. For the Timeline, you can copy events directly from the incident's automated audit trail — click **Import Timeline** to populate it from the recorded state changes and updates. Choose the appropriate severity level from the dropdown. This is used when filtering incident history and generating SLA reports. Click **Save Post-Mortem**. The document is permanently attached to the incident and visible to all team members with access to your workspace. ## Incident History and Audit Trail Every event in an incident's life is recorded as an immutable `IncidentEvent` entry. PulseGuard captures four event types automatically: | Event Type | When It Is Created | | -------------- | ------------------------------------------------------------------------- | | `STATE_CHANGE` | Every time the incident status changes, including creation and resolution | | `ALERT_SENT` | When a notification is dispatched to a channel | | `AUTO_RESOLVE` | When PulseGuard automatically resolves the incident on monitor recovery | | `COMMENT` | When a team member manually adds a timeline update | The complete audit trail is preserved indefinitely. You can filter incident history on the **Incidents** page by status, severity, date range, or affected monitor. This makes it straightforward to answer questions like "how many HIGH-severity incidents did we have last quarter?" or "what was the total downtime for this specific service over the past 30 days?" Use the incident history as a data source when compiling SLA reports or presenting reliability metrics to stakeholders. The combination of automated check data, incident timelines, and post-mortems gives you a complete, auditable record of your infrastructure's health over time.