Incident Management Platform  ·  View 01 of 34  ·  1 · Context and scope

System Context

The signals the platform consumes, the people it serves and informs, what it reaches to wake a human, and the two dependencies it borrows but must survive losing.

Editable source SVG draw.io All views
Signals it receives Monitoring and alerting metric · log · synthetic Email and ticket sources vendors · helpdesk People it serves and informs On-call responder Incident commander Rotation owner Service owner Stakeholders What it reaches Voice and SMS carriers two, independent Apple and Google push APNs · FCM Mattermost · tracker channels · action items Incident Management Platform 400 responders · 25 rotations What it borrows, and must survive losing Corporate identity provider federated only Delivery pipelines deploy · change events signed webhooks SMTP · webhook acknowledges coordinates schedules · overrides reviews · noise updates · status page SIP · SMPP critical alerts channels · actions SSO change events Incident Management Platform — System Context External / third party Person or role synchronous event / async v 1.0 · owner Reliability Architecture · date 2026-09

Decisions

  • The platform consumes alerts and never evaluates metrics or owns alerting rules. A monitoring system that is wrong about a threshold is fixed where the threshold lives; this platform decides only who hears about it.
  • Carriers, Apple and Google push are drawn outside because they are. No on-premises design owns the last mile to a phone. What the design owns is the diversity: two carrier routes with separate contracts and separate network paths, and never push as the only channel for SEV1 or SEV2.
  • The corporate identity provider and the delivery pipelines sit in the bottom row on purpose. The platform uses both and depends on neither to page: acknowledgement needs no login, and a missing change feed costs context, not a page.

Assumptions

  • One organisation, 400 responders, 40 services, 25 rotations, three timezones, 5,000 incidents and 60,000 notifications a month. All figures are the requirement's stated assumptions.
  • The requirement names Google Cloud with an out-of-cloud notification provider. This design runs the same problem on hardware the organisation owns, with open-source software only; the mapping is in the README.

Deliberately out

  • Metric evaluation, alert rule authoring, status-page hosting for external customers beyond a static page, and chat itself. Mattermost and the issue tracker are integrations, not components.
All views High-Level Architecture — Two Planes, One Loop  ▶
Solution Architecture v1.0 · Reliability Architecture · 2026-09 · 34 views · open source, fully on-premises01-system-context