Low-traffic systems age in place. They can sit for weeks looking perfectly composed while credentials expire, permissions drift, indexes lose contact with their sources, and background workers retain assumptions nobody has exercised since the last upgrade.
This is a different problem from a busy service failing under load. Activity would reveal some of these faults almost immediately. A quiet service gives them time to become part of the furniture.
I don't solve that by making the system chatter. I schedule a small end-to-end capability rehearsal that creates a synthetic unit of work, carries it through the ordinary path, reads the durable result, and removes it through the supported lifecycle. The rehearsal isn't traffic for traffic's sake. It keeps dormant state from receiving lifetime tenure.
Myth: untouched state stays stable
A service can remain unchanged while its operating context moves around it. A credential reaches its expiry. A dependency tightens a protocol. A storage permission changes during unrelated maintenance. A background worker restarts under a new default. A cached authorization decision remains comfortable until the next real request asks it a question.
None of these requires an incident. Time is enough.
Low use makes the effect harder to encounter. A frequently used write path keeps exercising authentication, validation, durable storage, and retrieval. A quarterly administrative action may touch all of those only when somebody genuinely needs it. The first real use then becomes an integration test with consequences attached, which is a fairly rude way for a system to reintroduce itself.
I treat idle capability as perishable. The code may not decay, but the agreements around it do. Any path that crosses credentials, scheduled processing, durable state, and later retrieval can become invalid one boundary at a time while the process remains comfortably alive.
Myth: component checks exercise the capability
Individual components can pass their own checks without completing the job. The API can accept a request while its worker can't claim it. The worker can transform a payload while the durable write is rejected. The read path can return an old fixture while new records are being stored somewhere the application never queries.
The rehearsal begins where ordinary work begins. It submits a clearly synthetic record through the supported entry point with values designed for testing, not copied from private material. It follows the same authentication and routing path, waits for the normal background transition, and retrieves the result through the interface the capability actually exposes.
Each rehearsal has a unique test identity so cleanup can't select real records by a broad pattern. The payload is harmless, bounded, and recognizable. If the workflow sends external messages or produces another effect that can't be safely rehearsed, I stop before that boundary and provide a dedicated test sink. The point is to exercise the full safe capability, not to create realistic collateral damage.
This full-path run catches seams that component checks are structurally unable to see: permission agreements between processes, serializers on opposite sides of a queue, state transitions that require a worker, and read models that update only after another step finishes. A green process list can't negotiate those contracts on my behalf.
Myth: a read-only rehearsal is always safer
Reading a known object is useful for a read capability. It is weak proof for a workflow whose job is to create, change, or retire state. Old data can remain readable through a path that no longer accepts new work.
For a write-oriented service, the synthetic record has to cross the mutation boundary. I want the application to validate it, persist it, perform the ordinary secondary work, and expose the result. Then the cleanup action must use the supported deletion or retirement mechanism rather than reaching directly into storage.
Cleanup is part of the rehearsal because hidden-state decay can live there too. A system that still creates records but can no longer remove them isn't fully capable. Neither is one whose cleanup removes the visible record while leaving derived state, attachments, or search entries behind.
I verify the synthetic identity at every destructive step. The cleanup command refuses a target that lacks the test marker or has acquired relationships outside the rehearsal. Safety comes from narrow selection and preconditions, not from pretending the write path can be tested without writing.
There is a tradeoff. Synthetic work can pollute reports, trigger integrations, or leave debris if designed carelessly. I exclude its marked identity from ordinary summaries where appropriate, route external effects to test destinations, and make incomplete cleanup a failure of the rehearsal. If I can't create a harmless unit of work, that itself tells me the service has no safe way to prove its write lifecycle.
Myth: one successful rehearsal buys permanent confidence
The schedule has to follow the mechanisms that age. I run the rehearsal after changes to identity, routing, storage, background processing, or the application’s data model. I also run it on a calendar for capabilities that may otherwise remain dormant through several dependency changes.
I don't choose the cadence from a generic desire to test more. I look at credential lifetimes, upgrade rhythm, cleanup policy, and how long I’m willing to discover that the capability has been quietly unusable. A low-consequence archival tool can justify a relaxed cadence. A rare but important recovery action deserves rehearsal before the day it becomes the only available move.
The run result records which boundary stopped and whether the synthetic state was fully removed. It doesn't calculate a universal health score. A failed create, stalled background transition, unreadable result, and refused cleanup lead to different repairs. Keeping those steps distinct makes the rehearsal a diagnostic path rather than a ceremonial green light.
There’s also no value in retrying the whole sequence until it passes and discarding the first failure. If a second attempt works, the intermittent boundary still deserves attention. Dormant systems are already good at hiding. The rehearsal shouldn't help.
Quiet operation can be exactly what I want. I don't need a rarely used tool inventing work to look busy. I do need its capability to survive the calendar. So I give it one synthetic job from entry through cleanup, on purpose, before a real task arrives and discovers which hidden agreement aged out.