Measure recovery at the user's endpoint

Define a complete endpoint check

Choose a workflow that starts from the normal public or private entry point used by clients. Include login where required and a meaningful read or controlled mutation.

A direct request to the target instance bypasses routing and name resolution. It is useful for diagnosis but should not be the only acceptance evidence.

Use identifiable synthetic data so the result can be inspected without confusing it with ordinary business activity.

Record the recovery timeline

Measure failure detection, decision time, activation, traffic transition and workflow completion separately. This exposes delays that a single infrastructure metric hides.

Include different client paths where they matter. Existing connections and cached routing information can behave differently from a fresh test request.

Report what was observed rather than promising that every client switches at one exact instant. The application's retry and reconnect behaviour forms part of the user experience.

Establish the data boundary

Check which committed operations are present in the active recovery region. Compare with known transaction evidence around the failure.

Separate operations that were confirmed to the user, operations with an unknown outcome and work safely held for later execution. They need different reconciliation actions.

A low replication-lag metric does not establish that every important business effect is represented. Use the platform's state and application-level evidence together.

Include sustainable operation

Continue the test long enough to observe capacity, resumed queues and essential integrations. A recovery region can serve a few checks successfully while falling behind under normal demand.

Track errors and latency by workflow, and identify any deliberately degraded capability. Make the limitation visible to the decision owner.

Acceptance should state the achieved recovery time, data outcome and supported workload. These are the facts needed to judge the design. A green promotion event is one milestone within that evidence, not the final result.

Make missing work visible in the report

Suppose a drill confirms 100 synthetic operations before interruption. The recovered database contains 98, and the remaining two have confirmed outcomes in a safe external test service. Report those two as reconciliation work rather than describing the database as fully current. If reconciliation completes seven minutes after traffic resumes, record that separately from initial service availability. This gives the business a clearer account of what users can do and which records remain uncertain.