Service Runbook Website Design

Auth-Service Runbook Design

This official OpenDesign website example presents a Northwind identity-service runbook as a single operational reference. The authored heading is “auth-service,” followed by ownership, version, review date, and the “TIER 0 · PRODUCTION-CRITICAL” status. That opening establishes the service’s responsibility before the reader reaches alerts or commands.

The service summary names session-token issuance, validation, and revocation across web, mobile, and the public API. It also identifies the password store, TOTP/WebAuthn enrollments, and audit-log writer. This makes the page useful for orientation: a responder can see which customer-facing and security-related responsibilities belong to the service before selecting a procedure.

Operational Tasks Supported

The design serves several related tasks without splitting them into separate pages. Its ordering moves from service scope to dependencies, then alerts, procedures, on-call coverage, and incident response. That sequence reduces the need to interpret an alert in isolation: the reader first learns what the service owns, then how to respond when one part is impaired.

The dependency list repeats a name-and-state pattern for Postgres, Redis, KMS, SES and Pager. Four entries are marked healthy, while SES · transactional is marked degraded. The right-aligned states support scanning, but they are a snapshot of the sample design, not demonstrated live health checks.

From Alert To Procedure

The alert section is designed as a four-column decision surface: alert, severity, what it means, and first response. For example, “auth.login_5xx_rate greater than 1%” is paired with “SEV-1,” a customer lockout explanation, and guidance to inspect Postgres and Redis dashboards. The explicit threshold gives the responder a trigger, while the prose supplies interpretation; the tradeoff is that the sample values still need a verified monitoring source in a real runbook.

The procedure section changes rhythm from compact rows to large blocks with a heading, usage note, explanatory sentence, and command panel. “Deploy a new version” states that the flow is blue/green and waits for two consecutive healthchecks before promotion. The visible traffic sequence, “10% / 50% / 100%,” communicates staged rollout, while the larger block consumes more vertical space in exchange for safer command-level reading.

Commands And Constraints

The procedure blocks keep action and caution adjacent. Rollback is labeled for use when the post-deploy error rate exceeds 1%, while signing-key rotation says “Schedule with security; never solo.” The audit-log procedure is explicitly tied to the backlog alert. These pairings show a useful information design choice: the command is not presented as sufficient on its own, and the surrounding condition defines when it belongs in the workflow.

Incident Sequence And Capability Boundary

The final incident-response section converts the first thirty minutes into five numbered cards. The sequence begins with acknowledgement within five minutes, opens a dedicated incident channel, requires a status snapshot every ten minutes, prioritizes mitigation, and ends with handoff or stand-down. Numbering makes the intended order visible; the two-column arrangement keeps the first four actions compact, while the fifth card spans only its own content.

This is a design-only website example. The captured page visibly presents commands, statuses, names, and sample outcomes such as “rolled back to v4.7.2 in 38 s,” but it does not establish that those commands execute, that the services are connected, or that the displayed operational results were measured. Adaptations should preserve the distinction between documented guidance and verified runtime data.

1. Acknowledge The Page

   The design begins with /ack and a five-minute response window, establishing the first coordination obligation.

2. Open The Incident Channel

   The second card names the service and short-title pattern used to create a dedicated response space.

3. Post A Status Snapshot

   The third card compresses customer impact, current knowledge, and next checks into a repeatable update.

4. Mitigate And Hand Off

   The last two cards prioritize rollback or security escalation, then define handoff and closure.