All classifiers
Decision chainIT & incidents4 steps · 7 endpoints

Incident alert triage

Filter noise, check customer impact, propose a severity, and look for a recent change to blame.

Scenario paths

Pick a predefined path to highlight it through the chain. No model is called; outcomes are illustrative.

Steps
  1. Alert actionability
  2. Customer impact signal
  3. Proposed incident severity
  4. Change-related incident signal
Endpoints
  • Log only
  • Attach to open incident
  • Alert tuning ticket
  • Team ticket
  • Notify change owner
  • Page incident commander
  • On-call review
What each endpoint means
  • Log only · Automated

    Recorded on the service's dashboard; nobody is paged.

  • Attach to open incident · Automated

    Added to the incident's timeline.

  • Alert tuning ticket · Automated

    A ticket for the alert's owner to fix the threshold.

  • Team ticket · Automated

    A ticket in the owning team's queue for working hours.

  • Notify change owner · Human review

    The person who shipped the change is asked to assess a rollback with the on-call engineer.

  • Page incident commander · Human review

    An incident is opened and the commander confirms severity.

  • On-call review · Human review

    The on-call engineer looks at it directly.

Steps

  1. Separate real problems from noise.

    Question, inputs and notes

    Asks:Does this alert need someone to act on it now?

    Receives

    • Inputalert
    • Inputhistory
    • Inputopen_incidents
  2. Find out whether customers are affected.

    Question, inputs and notes

    Asks:Do these signals indicate that customers are affected right now?

    Receives

    • Inputalert
    • Inputcustomer_signals

    Branches

    • Customer impact likely, Unclear: Unclear impact is treated as possible impact.
  3. Propose a severity for the commander to confirm.

    Question, inputs and notes

    Asks:Based on what is known, which severity level fits this incident best?

    Receives

  4. Look for a recent change that explains it.

    Question, inputs and notes

    Asks:Could one of these recent changes plausibly explain this alert?

    Receives

    • Inputalert
    • Inputrecent_changes

About this chain

Goal and input

Every alert ends logged, attached to an incident, sent for tuning, in a team queue, with the change owner, or with an incident commander.

The alert, its history, open incidents, customer signals and recent changes.

alert
The alert that fired.
history
Fire/resolve counts, computed in code.
open_incidents
Open incidents for the service.
customer_signals
Recent tickets and synthetic checks.
recent_changes
Deploys and config changes with minutes before the alert.
How it runs
  • Severity is always a proposal. The commander confirms it, and hard paging rules owned by each team still apply in code.
  • Nothing in this chain rolls back, silences or deletes anything automatically.
Sources (3)

Primary documentation this chain builds on.