Triage with context#
- Open the incident from the incident list or notification link. Confirm the service, severity, affected resource, environment, and source timestamps.
- Review the owning team, current on-call responder, runbook, related alerts, and matched routing rule. A repeated alert is not necessarily a new incident.
- Inspect the timeline and notification history before acting. Another responder may already have acknowledged or resolved it.
Incident states#
| State | Meaning | Next action |
|---|---|---|
| TRIGGERED | An active response is needed and the escalation policy may be running. | Acknowledge if taking ownership; investigate or escalate as needed. |
| ACKNOWLEDGED | A responder has accepted responsibility. This does not mean the system has recovered. | Investigate, coordinate the fix, and resolve when appropriate. |
| RESOLVED | The incident lifecycle has been closed manually or by applicable source recovery. | Review the history; a later alert lifecycle can create another incident. |
Acknowledge#
Select Acknowledge when you are taking responsibility. AckNexa records the actor and time and cancels pending escalation jobs and unsent notifications in the same transaction. A notification request already in flight can still complete; a late message does not necessarily mean the ACK failed.
Escalate and resolve#
Use the permitted escalation or assignment controls when more help is needed. Check that the destination is an active responder or valid policy target. Changes are visible in the incident history.
Resolve only when the response can be closed, and provide a meaningful resolution reason. A valid source recovery can also resolve the lifecycle. Older, out-of-order source data must not replace newer state. Manual resolution does not make a still-firing monitor healthy.
Notes, updates and tickets#
- Add notes to record what you checked. Notes stay internal unless you tick Send to stakeholders, which posts the note as an update to everyone following the service or team. See Status pages and stakeholders.
- Publish a customer-facing update from the incident's Status page update panel when the service is listed on a status page.
- Open a Jira or Halo ticket with Create ticket when your organization has a ticketing connection. See Ticketing.
- After resolution, start the review from the incident. See Postmortems.
Severity and ownership#
AckNexa normalizes severity to P1 through P5, with P1 highest priority. Agree on a severity mapping for your organization and integrations. Business criticality describes the service; it is not a substitute for incident severity. Acknowledge and resolve rights depend on your role, not on merely receiving a notification.
A good handoff#
- Link to the incident instead of copying credentials or private payloads into chat.
- Explain symptoms, checks already performed, the relevant runbook, and the next expected action.
- Confirm that the receiving responder has actually acknowledged. Provider acceptance or a ringing phone is not an acknowledgement.
- Keep sensitive information out of alert summaries when it is not needed for response.