One worker identity in a fleet that reads two values at start-up logged 40,000 reads yesterday — what does that volume establish?

## Do the arithmetic before anything else The fleet's shape gives you a divisor, so use it. Two reads per start and 40,000 reads implies roughly **20,000 starts** in a day. Against a fleet that deploys a handful of times a day and otherwise runs steadily, that is not a percentage departure — it is three orders of magnitude, about fourteen starts per minute sustained. Saying the number out loud matters in an interview, because it changes what you are claiming. "Reads are up" is a hunch. "This identity performed 20,000 start-ups in a day for a job that starts a few times a day" is a statement someone can confirm or refute in a minute, and it is what makes the rest of the conversation concrete. ## What the count establishes, and what it does not **Establishes:** a departure worth explaining. The volume is beyond any need the job has, so either the job is not behaving as designed or the credential is not being used by the job. **Does not establish:** that this is abuse. At least four things produce the same count: - a worker in a **restart loop** — it crashes, is replaced, reads its two values, crashes again; the count is a symptom of a crash, not of theft - a caller that **stopped caching** — a change removed an in-process cache, so a value that was read once per start is now read per unit of work - a **retry storm** against a downstream system, where each retry path re-fetches the credential instead of reusing it - **bulk harvesting** — somebody reading everything they can reach, quickly, before anyone notices Every one of those is composed entirely of permitted reads by a valid credential. None of them registers as a failure anywhere. ## The dimensions that separate them | Also observed | Points toward | |---|---| | Same two names, same source, same hours | an operational fault in the fleet | | Same names, but a source never seen before | the credential in use somewhere the fleet does not run | | Many distinct names, or a first-ever listing | reaching beyond need, not a fault | | Concentrated in a window the service does not run | a caller unconstrained by the service's schedule | | A burst of issuance requests alongside the reads | one identity asking the store to mint far more than it has ever needed | This is the practical reason a baseline is a set of fields rather than a single counter. Volume on its own is ambiguous by construction; volume plus a second moved dimension is a much narrower story. ## The counter you actually want A raw daily total is the wrong shape for this job. Two better ones: 1. **Reads per start, per identity.** For this fleet the expected value is exactly two. A worker reading two values thirty times per start is a different and more interesting finding than a worker starting thirty times. 2. **Reads against the job's stated need.** Recording that the job needs two names lets you express the departure as a ratio rather than a number, which travels across identities with different shapes. Both of those are per identity. An estate-wide reads-per-hour graph would absorb 40,000 extra reads without a visible bump in most estates, which is precisely how this kind of activity stays quiet. ## Why the operational causes are not a reason to ignore it It would be easy to conclude that because restart loops are common and harvesting is rare, a volume signal is mostly noise. Two reasons that conclusion is wrong. First, the common causes are worth knowing about anyway: a crash-looping fleet and a cache that silently stopped are both real production defects, and this signal found them. Second, and more importantly, **the cost of the check is an explanation, and the cost of skipping it is unbounded.** The signal's job is to make somebody say out loud why 40,000 reads happened. If the answer is "the workers were crash-looping between 02:00 and 04:00", that is a good outcome and takes minutes. If nobody can produce an answer, that absence is the finding, and it arrives with the identity, the time window and the names already attached — which is a far better starting position than learning about it from somewhere else weeks later.