Build an incident process a small team can use

An incident process fails when the on-call engineer cannot use it under pressure. Put customer impact, first checks, command ownership, and escalation on one screen. Link deeper reference material from there.

Build the first version from recent incident evidence. The actions people took, the tools they opened, and the handoffs that slowed recovery should define the document.

Design the first screen for the on-call shift

The first screen should name the customer symptom, the service owner, the first diagnostic checks, and the escalation path. Each step should use a tool available to the on-call engineer.

Use the service names people use in chat and alerting. If the team says “billing worker,” keep that name in the playbook and link it to the repository or service record.

• Customer symptom and affected action
• Incident lead and service owner
• First three checks with direct links
• Escalation path and update cadence
• Recovery and rollback conditions

Fit the roles to the team

A large response can separate incident command, communications, and operations. A twelve-person engineering team may assign those duties to one lead and one operator. Document the staffing model the current rotation can support.

Write a fallback for each role. The process should say who takes command when the named lead is debugging and who updates customers when product support is unavailable.

Use three severities for a small product team

Use severity to set the audience, update cadence, and escalation path. Three levels cover a customer-facing failure, a degraded core action, and an internal problem for many product teams.

• Sev 1: customers cannot complete a core action. Updates every 30 minutes.
• Sev 2: a core action is slow or partially broken. Updates every 60 minutes.
• Sev 3: internal tools or a non-core path. Handle in business hours unless it is spreading.

Close the review loop

Schedule the review within a week and invite the responders who handled the failure. Select one or two actions, assign owners and dates, and connect each action to the observed failure mode.

Each quarter, compare the playbooks with recent incidents. Remove skipped steps, add the checks responders used, and verify that links and ownership still match the live system.