Uptime Monitoring: Incidents
Overview
Use this page to view, filter, and manually resolve uptime monitoring incidents. An incident is a record automatically created when an uptime check, an HTTP, DNS, TLS, or ICMP probe, fails; it captures the failure reason, when it started, and when it ended. Incidents let you see exactly which target is down and why, without digging through raw check logs.
Incidents only exist because checks exist first: you define what to monitor on the Uptime Monitoring: Checks page, and every failed run there raises or extends an incident here. Once an incident closes, automatically when the check recovers or manually from this page, it stays in the list as a historical record you can filter by check, status, and date range for uptime audits.
This page lets you filter the incident list by check, status, and date range, inspect the details of a single incident including its endpoint, environment, tags, and dependencies, and manually close an incident stuck Open, for example when the underlying issue was already fixed outside LoadGen's detection window.
Key concepts
- incident - A record created automatically when an uptime check fails; it tracks the failure reason, start time, and, once closed, end time and duration. (related: Uptime Monitoring: Checks)
- check - A scheduled probe, such as HTTP, DNS, TLS, or ICMP, that tests a target and raises an incident when it fails. (related: Uptime Monitoring: Checks)
- status (Open / Resolved) - Whether an incident is still active, Open, or has been closed, Resolved.
- resolution - How a Resolved incident was closed: automatically once the check succeeds again, shown as an Auto badge, or manually by an operator from this page.
When to use it
- After an alert or notification about a failed check, to see what failed and why.
- When investigating whether an outage on a monitored target is still ongoing or has already recovered.
- Before closing out an incident ticket, to confirm whether an incident resolved automatically or still needs manual closing.
- When auditing uptime reliability for a specific check over a date range.
- When a check's failure isn't clearing on its own and you need to stop it from showing as Open.
Before you begin
- At least one uptime check is configured and has run, created on the Uptime Monitoring: Checks page; incidents are only created when a check fails.
- If you plan to narrow results with From Date and To Date, know roughly when the failure started so you can set a matching range.
Common workflows
Filter incidents to the active ones
Persona: load-test operator
- Select Open from the Status dropdown.
- Expect: The Status field now shows Open; the table has not reloaded yet.
- Select Apply.
- Expect: The table reloads to show only incidents still in progress; Resolved rows disappear from the list.
Verify: Every remaining row shows Status Open, a dash in End Time, and Duration reading Ongoing.
Manually resolve a stuck incident
Persona: load-test operator or admin
- Select the row for an Open incident, for example one with Failure Reason ICMP status: TimedOut.
- Expect: The Incident Details panel opens, showing the check's endpoint, environment, tags, affected dependencies, and a running Duration marked Ongoing.
- Select Resolve incident manually.
- Expect: A confirmation prompt appears: Close this incident now? The next failed check on this target will open a new incident.
- Confirm the prompt.
- Expect: The incident's Status changes to Resolved, an End Time and Duration are stamped, and the panel closes.
Verify: Filtering Status to Open no longer lists this incident; filtering to Resolved shows it with a populated End Time and Duration.
Steps
Step 1
Open the Incidents page under Monitoring and Uptime.
Expected result: The page loads with the filter toolbar, Check, Status, From Date, To Date, set to show all incidents, and the table lists each incident's Status, Check Name, Failure Reason, Start Time, End Time, Duration, and Resolution.
This is the starting point for spotting which checks are currently failing and reviewing past failures.
- The Check filter defaults to All Checks and the Status filter defaults to All, so the table starts unfiltered.
- Open incidents show a dash for End Time and Duration reading Ongoing, while Resolved incidents show a populated End Time, a computed Duration, and an Auto Resolution badge.
Field reference
| Field | Purpose | Format / Validation | Required | Default |
|---|---|---|---|---|
| Check | Limits the incident list to incidents raised by one specific check; leave it at All Checks to see incidents from every check at once. | dropdown, list of configured check names | No | All Checks |
| Status | Limits the list by incident state; select Open to focus on failures still needing attention, or Resolved to review closed incidents for auditing. | dropdown | No | All |
| From Date | Sets the earliest incident Start Time to include; combine with To Date to narrow results to a specific outage window. | date, dd/mm/yyyy | No | - |
| To Date | Sets the latest incident Start Time to include; leave blank with only From Date set to see everything from that date onward. | date, dd/mm/yyyy | No | - |
Column reference
| Column | What it shows | How to read it |
|---|---|---|
| Status | Shows the current state of each incident. | Open means the check is still failing; Resolved means the check recovered or the incident was closed manually. |
| Check Name | Identifies which uptime check raised the incident. | Matches the check name as configured on the Uptime Monitoring: Checks page. |
| Failure Reason | Describes the specific error the check returned. | Read this first to understand what actually failed before investigating further. |
| Start Time | Timestamp of the first failed run that opened the incident. | Use it to correlate the incident with other events around the same time. |
| End Time | Timestamp when the incident closed. | A dash means the incident is still Open; a populated value means it's Resolved. |
| Duration | Elapsed time the incident was, or has been, open. | Ongoing means the clock is still running on an Open incident; a fixed value means it's Resolved. |
| Resolution | Indicates how a Resolved incident was closed. | Auto means the check started passing again on its own. A dash means the incident hasn't been resolved yet. The info icon next to the header offers more detail on hover. |
Controls reference
Apply
Reloads the incidents table using the current Check, Status, From Date, and To Date values.
When to use: After changing any filter field, to apply it to the displayed list.
Side effects: Read-only; only changes which rows are displayed, no incident data is changed.
Clear
Resets Check to All Checks and Status to All, empties From Date and To Date, then reloads the table.
When to use: To remove all active filters and see the complete incident list again.
Side effects: Read-only; resets the filter inputs and reloads the table.
View incident
Opens the Incident Details panel for the selected row, showing monitored signals, endpoint, environment, tags, affected dependencies, Start Time, End Time, and Duration.
When to use: To get full context on a failure before deciding whether to wait for automatic recovery or resolve it manually.
Side effects: Read-only; opens a detail view, no data changes.
Resolve incident manually
Closes an Open incident immediately, after you confirm the prompt: Close this incident now? The next failed check on this target will open a new incident.
Side effects: Mutating; sets the incident's Status to Resolved and stamps an End Time and Duration. The button reads Resolving while the change is applied. Any future failure on that same target starts a brand-new incident rather than reopening this one.
Verify the result
After opening Incidents, the table lists every uptime incident with its Status, Check Name, Failure Reason, and timing columns populated. Open incidents show a dash for End Time and Duration reading Ongoing; Resolved incidents show a populated End Time, a computed Duration, and an Auto Resolution badge. Selecting Apply after setting filters narrows the table to match, and Clear returns it to the full list. If you expect an incident to appear and it doesn't, check first whether the Check or Status filter is narrowing it out.
Troubleshooting
- Symptom: The table is empty after selecting Apply. Fix: Check that the Status and Check filters aren't excluding every incident in the selected date range; select Clear to remove all filters and confirm incidents exist at all.
- Symptom: An incident stays Status Open and Duration keeps reading Ongoing even though the underlying issue is fixed.
- Symptom: The Resolution column shows a dash for a row. Fix: This is expected while the incident is Open; the Resolution badge only appears once the incident is Resolved.
- Symptom: A new incident opens for a target you just resolved manually. Fix: This is expected; resolving an incident only closes the current one, the next failed check on that same target always opens a new incident.
- Symptom: Incidents you know happened don't show up when filtering by date. Fix: Confirm From Date and To Date bracket the Start Time of the incident, dates filter on when the incident started, not when it ended.
Related articles
- Prerequisite: Uptime Monitoring: Checks - checks must be configured and run before they can raise incidents here
- See also: Uptime Monitoring: Dashboards - aggregate uptime status across checks, as a counterpart to the incident-level detail here
- See also: Uptime Monitoring: My dashboard - a personalized summary view of uptime monitoring results
- See also: Uptime Monitoring: Maintenance - schedule planned downtime so expected outages don't need manual incident resolution