# A recovery check must also leave a working system alone

By Andrew Proctor · Published September 14, 2026, updated September 15, 2026

A recurring network problem had required a manual route repair. I replaced that repair with a check that follows the current gateway.

Restoring the route was one requirement. The check also needed to leave a correct route alone. Otherwise, something intended to restore connectivity could make unnecessary changes during normal operation.

## Test both states

We deliberately removed the route and confirmed that the check restored it. A second run confirmed that it left the working route unchanged.

Those observations answered two different questions about the repair. Seeing that a scheduled task exists would not have established either behavior. The test needed an actual missing route, followed by a state in which no repair was required.

## Keep the result bounded

The result was a checked recovery path for that recurring problem. It was not evidence that the network could recover from every failure. I kept the check tied to the condition it was intended to handle.

This small repair shows one place where the healthy state belongs in the acceptance criteria alongside the failure.

Related work: [Personal projects](https://raidz.net/projects/).

Further reading: [Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/).

Canonical HTML: [https://raidz.net/notes/recovery-checks/](https://raidz.net/notes/recovery-checks/)