Record the restore.

Pick the one you actually did. If you discussed the restore without running it, that is a tabletop walkthrough, and it is a legitimate exercise with a legitimate record.

Full restore into a clean environment

Recorded as a full restore when the team walked through the runbook in a meeting

Why the weak one costs you. These four evidence completely different things. A walkthrough evidences that people know the procedure and can make decisions; it says nothing about whether the backups are readable, which is the failure mode that actually bankrupts companies. Recording a discussion as a technical test is the one entry here that can turn a bad quarter into a serious problem, because it is a written statement that is straightforwardly untrue, and the way it surfaces is a real outage where the restore does not work.

Name what was restored and, in the same breath, the dependencies you did not exercise. DNS, identity, payment providers and third-party APIs are the usual omissions.

Restored prod-db-01 and the checkout API into an isolated us-west-2 environment. Did not exercise DNS cutover, the identity provider, or the payment gateway, all of which sit on the real recovery path.

Restored the production database successfully.

Why the weak one costs you. Every reader silently extends a narrow test to the whole system unless you stop them, and the untested dependency is usually where a real recovery stalls: the database comes back in twenty minutes and then nobody can log in because identity was never in scope. Drawing the boundary yourself costs nothing and is the difference between a record that survives scrutiny and one that is quoted back at you as an overstatement.

The number from your policy or your customer contracts, whichever is tighter. Say which.

4h (tightest customer MSA; internal policy says 8h)

4h

Why the weak one costs you. When the internal policy and the contract disagree, the contract is the one that gets enforced and the one people forget to check. Recording both, and which you measured against, prevents the conversation where a recovery finishes inside policy and outside the commitment you actually sold.

Measure from the moment the incident would have been declared to the moment the service was usable, and write down where you started the clock. Starting from the moment someone began the restore excludes the detection and decision time that a real recovery always contains.

5h 12m from declaration to first successful customer transaction. Clock started at declaration, not at restore start.

Restore took about 3 hours

Why the weak one costs you. Missing the target is a finding, not a failure, and it is the most useful thing this record can contain. What is not defensible is a number measured from a start point chosen after the fact: it makes the result unfalsifiable and incomparable to the next test. Naming the start point is what makes the measurement mean something, and it is the first thing anyone technical will ask about.

The committed number, from the same source as your RTO. If replication is asynchronous, the honest target is bounded by your replication lag, not by your backup interval.

15m

Near zero

Why the weak one costs you. A phrase like "near zero" cannot be tested, so it cannot be evidenced, and it will be read as zero by the customer who is quoting it back to you. Any number you can measure against beats any adjective.

Take the timestamp of the newest record present in the restored copy and subtract it from the moment of failure. Measure it in the restored data, not from the backup schedule.

22m (newest row in the restored copy 08:40; simulated failure 09:02)

15m, per the backup schedule

Why the weak one costs you. The schedule tells you when a job was supposed to run, which is a different claim from what the restored copy actually contains. Replication lag, a job that failed quietly, and a snapshot that completed after its nominal time all sit in the gap between the two, and that gap only ever becomes visible if you read the timestamp out of the restored data. Reporting the schedule is reporting your intent, and intent is exactly what a recovery test exists to check.

Name the source of the data, the runbook and its version, and who performed it. If it was done by hand because the automation failed, that belongs here.

Restored from the 2026-08-19 08:40 object-storage snapshot using runbook DR-04 v7, performed by Priya S. Step 6 was done by hand because the terraform module errored on the region variable.

Restored from backup.

Why the weak one costs you. Naming the runbook version is what lets a reader connect this record to the procedure that exists today, and a manual step recorded honestly is often the single most valuable line in the document: it means the automation you are relying on does not work, which nobody would have known from a record that just said the restore succeeded.

Say what you checked and what you saw. Row counts against production, a known transaction that only exists after a given date, a real login, a checkout that completes. Something that would fail if the data came back corrupt.

Row counts on the six largest tables matched production within expected drift. Retrieved order 8842001 (placed 08:31) intact. Completed a test checkout end to end against the restored copy.

Restore completed successfully with no errors.

Why the weak one costs you. A clean exit code tells you the restore tool ran. It does not tell you the data is complete, uncorrupted, or usable by the application, and every one of those has failed in the wild while the tooling reported success: a truncated table, an encoding change, an incompatible schema version. Without a verification step, the only thing this exercise evidences is that you can execute a command. This is the field most often left as one sentence, and it is the one an assessor reads first.

Name them and their role. If the person who normally would not do this ran it deliberately, say so, because that is a stronger test.

Priya S. | Platform engineering | present
Sam O. | On-call, ran the restore unaided as the test condition | present

The platform team performed the test.

Why the weak one costs you. If your most experienced engineer ran the restore from memory, you tested that engineer, not the runbook, and you learned nothing about what happens at 3am when they are unreachable. Handing it to someone who follows the document cold is a harder test and a much better one, and this is the only field where that choice gets recorded.

One line per step, with the clock time and what came of it. Include the waiting: snapshot transfers and DNS propagation are usually the bulk of the number.

09:47 | Snapshot transfer to us-west-2 | Completed 11:31, 1h 44m unattended

Restored the database

Why the weak one costs you. The measured RTO is a single number and tells you nothing about how to improve it. The timeline is where you find that two thirds of it was one unattended transfer, which is a procurement or architecture problem rather than a training one. Without this breakdown, the usual response to a missed target is to tell people to go faster, which is the one intervention that will not work.

One line per deviation, quoting the step. Include the ones you worked around in seconds, because those are the ones that will not be obvious to someone following it alone.

Step 6 | terraform apply | Errored on the region variable; applied by hand
Step 11 | Point DNS at the restored endpoint | Runbook names a hostname retired in March

Minor issues were encountered and resolved.

Why the weak one costs you. The deviations are the findings. A runbook step that references a retired hostname is a document that will fail the person using it at the worst possible hour, and the only moment it is ever discoverable is a rehearsal like this one. Summarising them as minor issues discards the entire output of the exercise: the record then shows you ran a test, but not the one thing the test found out.

State what was expected against what happened, then a named person and a date. One person, never a team.

Runbook DR-04 step 11 names a hostname retired in March | Priya S. | 2026-09-05

Runbook needs updating

Why the weak one costs you. A gap with no expectation, no owner and no date is a sentiment, and it will be read as one. Naming what was expected against what happened is what makes it checkable by someone who was not there, and naming a person is what makes it get done. The follow-up question after any exercise is what you found and what you did about it, and this field is the only place both halves live.