# Confirm write authority before changing regional traffic

During an outage, reachable does not necessarily mean safe to use. Establish which data path is authoritative before directing customers to it.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Identify the failure scope

Collect evidence from more than one relevant path where available. Distinguish an application failure, regional dependency failure and a routing or identity problem.

Record what remains reachable and whether the primary may still accept writes. Avoid declaring it stopped solely because the incident operator cannot connect.

Check the documented failover conditions and decision authority. Recovery can create data consequences, so the action should follow the service's agreed policy.

## Use the supported data transition

Follow the platform's promotion and fencing procedure. Record the resulting authoritative state and any known replication gap.

If the procedure cannot establish the required safety condition, use the documented degraded or paused mode. Do not improvise a second independent writer to make the website appear available.

Keep unresolved operations visible, especially those with external effects and lost responses.

## Move and verify traffic

Apply the intended routing change and observe requests through the normal client path. Check authentication, reads and a safe business operation.

Confirm background workers and integration callbacks use the active region appropriately. Public traffic can move while a scheduler remains connected to the old data path.

Monitor capacity and backlog as the recovery environment takes load. Be prepared to limit nonessential work under the predefined policy.

## Stabilise before planning failback

Record the active region, data boundary, temporary limitations and owners of reconciliation work. Communicate the actual service state to support teams.

Do not automatically return traffic when the original region becomes healthy. It may now contain an older history and need rebuilding or synchronisation.

Schedule the return under a controlled plan after the incident is stable. The immediate objective is a correct, supportable service in the recovery region. Restoring the original geography is a separate operation with its own data and verification requirements.

## Record an uncertain operation before retrying it

If a customer-facing request timed out during the transition, locate its operation identity and check the authoritative data path. For an external effect, inspect the provider's supported status lookup under the normal access policy. Keep the item in an unresolved state when evidence is insufficient. Creating a new operation identity to force a retry can bypass duplicate protection and make the incident harder to reconcile. The run record should show who owns that unresolved item.

## Sources

- [AWS: disaster recovery strategies](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)