Know when the work is working.
Choose signals, prepare recovery paths, and make failures understandable to the people operating the service.
A useful place to start.
A short reading path
- 01Choose monitoring signals that explain user impact
Observe the user journey and its dependencies.
- 02Write a runbook someone else can follow
Give operators a usable diagnostic and recovery path.
- 03Test a backup by restoring the application
Demonstrate that important records can be recovered.
Explore the topic.
Decide what an application health check should proveA running process does not necessarily mean users can complete their work. Health checks should answer specific operational questions without making the system less stable when a dependency has trouble.Choose monitoring signals that explain user impactMonitoring should help a team notice a problem and decide where to investigate. Collecting many numbers is useful only when someone can connect them to the service people depend on.Write a runbook someone else can followA runbook is useful when an operator can use it under pressure without already knowing the system’s hidden assumptions. It should connect a recognizable situation to a safe, observable response.Test a backup by restoring the applicationA backup file existing is only part of a recovery plan. The team also needs to know whether it can retrieve the right copy, restore the data, and use the application afterward.Prepare rollback before the releaseA rollback plan should explain which changes can be reversed and which effects remain. Keeping the previous application image is useful, but it does not automatically reverse data or external actions.Investigate a slow application before choosing a fix“Slow” can describe waiting for a page, submitting a form, receiving a background result, or navigating a large list. Start by identifying the experience before deciding which component to optimize.Design background jobs as visible workMoving a task into the background changes when it runs, not whether it needs a clear outcome. A job should have an identity, a lifecycle, and an operational path for failure.Write incident updates that support decisionsDuring an incident, people need to know what is affected, what they can do, and when they will hear more. A useful update separates observations from explanations that are still being investigated.Turn an incident review into useful follow-up workAn incident review should explain how the system reached an undesirable state and what would make a similar event easier to prevent, detect, or recover from. A timeline alone is not enough.Track email delivery beyond the send requestAn email provider accepting a request does not guarantee that the recipient can read the message. Applications should distinguish the stages that matter to the workflow and expose failures appropriately.
Put it to work
Infrastructure services
Connect the guidance to the application or systems you need to build or improve.
Explore the service ↗Engineering context
Server performance research
The server-performance publication documents a defined measurement workload. Read its conditions and limitations before comparing those results with an application’s operational targets.
Read the technical work ↗