Every incident in PulseAPI has a severity level: Critical, High, Medium, or Low. This article explains how severity is determined and how to use it effectively.
How Severity Is Determined
Severity is set by the alert rule that triggered the incident. When you create or edit an alert rule, you assign it a Priority (Critical, High, Medium, or Low). When that rule fires, the resulting incident inherits that priority as its severity.
This means severity is a deliberate signal — you configure it by designing your alert rules thoughtfully.
What Each Level Means
Critical
Immediate action required. This incident has significant user impact or threatens system availability. Examples:
- Production API returning 5xx errors
- Payment processing endpoint down
- Primary database unreachable
High
Significant problem that should be addressed quickly. Not yet causing major user impact, but could escalate. Examples:
- Response times degraded but not failing
- Staging environment down (potential signal of upcoming production issue)
- SSL certificate expiring within 7 days
Medium
Degraded performance or partial problem. Investigate when possible. Examples:
- Response times elevated but within acceptable bounds
- Non-critical endpoint down
- SSL certificate expiring in 30 days
Low
Minor issue; investigate when convenient. Not causing immediate impact. Examples:
- Intermittent check failures with quick recovery
- Non-user-facing internal endpoint down
Using Severity Effectively
Design your rules with severity in mind:
- Create separate rules for the same monitor with different thresholds and priorities. For example: one Critical rule for status code != 200, one Medium rule for response time > 3s, one Low rule for response time > 1s.
- Only use Critical for things that genuinely need immediate response — alert fatigue happens when everything is Critical.
Filter by severity in the Incidents list:
- Use the severity filter to focus on what matters most. Start your day by checking all open Critical and High incidents.
- Resolved Critical incidents are worth reviewing in post-mortems — use the filters to pull them up.
Related Articles
Still have questions? Contact support.
Related Articles
What Is an Incident?
An incident is PulseAPI's record of a problem with one of your monitors. This article explains what triggers an incident, what information it contains, and how it relates to alert rules. What Creates an Incident Incidents are created automatically — ...
Viewing Incident History
The Incidents page shows a full history of all incidents on your team — open, acknowledged, and resolved. This article explains how to navigate and filter the list. Opening the Incidents List In the left sidebar, click Incidents. Filtering Incidents ...
Key Concepts: Endpoints, Checks, Incidents, and Alerts
This article explains the four core building blocks of PulseAPI and how they work together. Understanding these concepts makes every other part of the product easier to use. Endpoint (Monitor) An endpoint is a URL you want PulseAPI to watch. In ...
Pulse AI Incident Analysis
Pulse AI automatically analyzes incidents and generates a summary of likely causes and recommended next steps. This article explains how it works, which plans include it, and how to use it. What Pulse AI Analyzes When an incident is created, Pulse AI ...
Resolving an Incident
Resolving an incident closes it — the problem is fixed and the endpoint is healthy. Incidents can be resolved automatically by PulseAPI or manually by a team member. Prerequisites: You must be a team Owner, Admin, or Member to resolve incidents. ...