Skip to main content
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.
1

Investigating

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.
2

Identified

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.
3

Monitoring

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.
4

Resolved

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

1

Open the incident

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.
2

Review affected monitors

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.
3

Add a timeline update

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.
4

Change the incident status

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.
5

Resolve the incident

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.

Global Incidents

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.

Regional Incidents

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:

Summary

A concise, plain-language description of what happened, who was affected, and for how long.

Timeline of Events

A chronological account of the incident, cross-referenced with the automated timeline entries PulseGuard recorded during the outage.

Root Cause

The underlying technical or process failure that caused the incident. Be specific — vague root causes produce vague action items.

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.

Severity Level

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:
1

Open the resolved incident

Navigate to Dashboard → Incidents, filter by Resolved, and click the incident you want to document.
2

Create the post-mortem

Click Write Post-Mortem. The editor opens with section prompts for Summary, Timeline, Root Cause, and Action Items.
3

Fill in each section

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.
4

Set severity

Choose the appropriate severity level from the dropdown. This is used when filtering incident history and generating SLA reports.
5

Save the post-mortem

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: 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.