Incident Lifecycle
Understand the full lifecycle of an incident -- from trigger through escalation, acknowledgment, and resolution.
Incident Lifecycle
Every incident in Seenty follows a structured lifecycle. Understanding this lifecycle helps you configure your alerting correctly and respond to incidents efficiently.
Incident states
An incident moves through three states:
| State | Meaning | What happens |
|---|---|---|
| Triggered | A monitor has crossed the failure threshold and an incident has been created | Escalation begins -- notifications are sent according to the escalation policy |
| Acknowledged | Someone on the team has claimed the incident | Escalation pauses -- no further steps fire. The incident remains open until resolved. |
| Resolved | The problem has been fixed | The incident is closed and a resolution event is recorded in the timeline |
Incidents always start as Triggered and always end as Resolved. The Acknowledged state is optional but recommended -- it tells your team that someone is actively working on the problem.
The escalation flow
When a monitor crosses the alert threshold (e.g., 2 consecutive failures), the following sequence begins:
Incident created (Triggered)
Seenty creates an incident linked to the failing monitor and assigns the escalation policy configured for that monitor. The incident status is set to Triggered.
Step 0 fires immediately
The first escalation step executes without delay. Seenty:
- Determines the notification targets (channels and/or the current on-call person)
- If an on-call schedule is referenced, resolves who is currently on-call
- Sends notifications to all targets through their configured channels
- Logs each notification in the incident timeline
If the target is an on-call person, their personal notification rules determine how they are contacted (email immediately, SMS after 5 minutes, etc.).
Wait for acknowledgment
Seenty waits for the delay configured on the next escalation step (e.g., 5 minutes). During this window, anyone on the team can acknowledge the incident to stop the escalation.
Step 1 fires if unacknowledged
If no one acknowledges the incident within the delay, Step 1 fires. A new set of notifications goes out to the contacts configured in Step 1, which might include a different on-call schedule, additional channels, or escalation to a manager.
Continue through all steps
The process repeats for each step in the escalation policy. Each step has its own delay and notification targets.
Escalation repeat (if enabled)
If all steps have fired and the incident is still unacknowledged:
- Repeat enabled: The escalation loops back to Step 0 and starts the chain again
- Repeat disabled: No further automatic escalation occurs, but the organization owner receives a fallback email
Acknowledging an incident
Acknowledging an incident signals to your team that someone is actively investigating the problem. When you acknowledge:
- The incident status changes from Triggered to Acknowledged
- All pending escalation steps are paused -- no further steps will fire
- An acknowledgment event is recorded in the timeline, showing who acknowledged and when
You can acknowledge an incident from:
- Web dashboard -- Open the incident and click Acknowledge
- Mobile app -- Tap Acknowledge from the incident detail screen
- Email -- Click the Acknowledge link in the alert email
Acknowledging pauses the escalation but does not resolve the incident. The incident remains open in the Acknowledged state until someone resolves it or the monitor recovers.
Resolving an incident
Resolving an incident marks the problem as fixed and closes the incident. There are two ways an incident gets resolved:
Manual resolution
Click Resolve on the incident detail page or in the mobile app. You can optionally add a note explaining what was done to fix the problem.
Automatic resolution
When the monitor that triggered the incident starts returning successful checks again, Seenty automatically resolves the incident. A recovery event is added to the timeline, and a recovery notification is sent to the same channels that received the initial alert.
Auto-resolution is the default behavior and is usually what you want -- it means incidents are automatically closed when the underlying problem is fixed, without requiring someone to manually click resolve.
The incident timeline
Every incident has a detailed timeline that records every event in chronological order:
| Event type | Description |
|---|---|
| Triggered | The incident was created because a monitor crossed the failure threshold |
| Notification sent | A notification was sent to a specific channel or person (includes delivery status) |
| Notification failed | A notification could not be delivered (e.g., invalid webhook URL, SMS delivery failure) |
| Escalation step fired | An escalation step was triggered because the incident was still unacknowledged |
| Acknowledged | Someone acknowledged the incident (includes who and when) |
| Resolved | The incident was resolved (manually or automatically) |
| Note added | A team member added a note (includes author, timestamp, and content) |
The timeline is the single source of truth for incident response. Use it to review how quickly your team responded, whether the escalation worked as expected, and what actions were taken.
Adding notes
Any organization member can add notes to an active or resolved incident. Notes are useful for:
- Documenting what you found during investigation
- Sharing updates with the rest of the team
- Recording the root cause and resolution steps
- Logging decisions made during the response
Each note shows the author's name, avatar, and the timestamp. Notes are added to the timeline in chronological order alongside other events.
Incident metrics
MTTA and MTTR metrics are available on Ultra plans and above.
For teams that want to measure and improve their incident response, Seenty tracks two key metrics:
- MTTA (Mean Time to Acknowledge) -- The average time between an incident being triggered and someone acknowledging it. A lower MTTA means your team is responding to alerts quickly.
- MTTR (Mean Time to Resolve) -- The average time between an incident being triggered and being resolved. A lower MTTR means problems are being fixed faster.
These metrics are calculated across all incidents and can help you identify patterns -- for example, whether incidents on weekends take longer to acknowledge, or whether certain types of failures take longer to resolve.