Incident Management Platform  ·  View 03 of 34  ·  2 · People and journeys

Actors — Who the Platform Is For and What They Get to Do

Six actors grouped by their relationship to the platform, each with the goal in their own words and the journeys that goal produces. Four of those journeys are mapped on the next pages.

Editable source SVG draw.io All views
People woken by it On-call responder ≈ 400 across 25 rotations Goal — Wake me only for something real, and let one keypress stop the pager. Core journeys Acknowledge a SEV1 at 03:12 Hand over at the end of a shift Pull a colleague in by role Incident commander every SEV1 and SEV2 Goal — Get the right people in one place, and keep stakeholders informed without letting them into the channel. Core journeys Run a SEV1 to mitigation Split a second failure out Post a stakeholder update People who own what it pages for Rotation owner 25 rotations · 3 timezones Goal — Hear about the hole in my rotation a week before it matters, not when a page fails. Core journeys Close a coverage gap before DST Approve a holiday override Chase an unverified phone number Service owner 40 services Goal — Pay less for noise, and make the review the least effort of anything I do that week. Core journeys Close a review and its actions Read the weekly noise and cost report Declare a maintenance window Machines and readers Monitoring system Alertmanager · synthetics Goal — Hand an alert over once, retry safely, and be throttled rather than dropped. Core journeys Retry a webhook after a timeout Survive its own quota Stakeholder support · leadership Goal — Know what customers see and when I will hear next, without joining the incident. Core journeys Read a templated update Check the status page Actors — Who the Platform Is For and What They Get to Do Person or role Journey / task Security / platform External / third party v 1.0 · owner Reliability Architecture · date 2026-09

What the grouping says

  • The first group is woken by the platform, and it is the group whose trust decides whether the platform works at all. A responder who has learned to ignore the pager has turned the best escalation engine into a noise generator.
  • The second group owns what the platform pages for. Their journeys are slow and happen weeks before an incident: a coverage gap found early, a review that changes something. That is where most future pages are prevented.
  • Monitoring systems are actors because their behaviour under stress, retrying and flooding, is a design input. A webhook that retries on timeout is exactly the duplicate the ingest path must absorb.

Journeys mapped

  • View 04: a responder woken for a SEV1. View 05: an incident commander running it. View 06: a rotation owner closing a DST gap. View 07: a service owner turning a review into changed conditions.

Deliberately not an actor

  • Executives as incident participants. They are stakeholders who receive templated updates with a next-update-by time, which is what keeps them out of the responder channel.
◀  High-Level Architecture — Two Planes, One Loop All views Journey — An On-Call Responder Is Woken for a SEV1 at 03:12  ▶
Solution Architecture v1.0 · Reliability Architecture · 2026-09 · 34 views · open source, fully on-premises03-actors-and-journeys