Your teams run critical stores on managed tiers with no host access — how do you keep opaque incidents from becoming an unbounded risk?

## Why the risk is unbounded rather than merely large When you operate the machine, your worst case is bounded by your own capability: with enough evidence and enough engineers, you eventually see the fault. On a **managed tier** the worst case contains a term that is not yours. Once the signals a tenant can see are exhausted — exported instance metrics, the engine's own statistics, your client telemetry, the tier's event feed — the next fact arrives from a support queue, on a schedule set by the provider's severity routing and its own engineering load. No amount of your own effort shortens it. That is not an argument against managed tiers; the alternative spends scarce operational attention on patching, backups and failover drills. It is an argument that the *shape* of your risk changed when you adopted them, and that the controls have to change with it. You cannot bound the provider's term, so you bound everything around it. ## The four requirements that do most of the work 1. **Client-side telemetry as a precondition of adoption.** Per-call latency distribution, timeout counts and connection-pool wait time, sampled finer than the tier's metric export window and retained long enough to compare against the last good night. This is the only instrument you own, and it answers the question that decides the first fifteen minutes of every incident: did the request reach the engine at all. 2. **A mitigation that needs no reply.** For each critical store, at least one action that restores acceptable service without the provider answering anything — shed or shape load, degrade a feature, serve a stale view, route reads to a standby that already exists, back-pressure at the edge. Prefer at least one that is not itself a control action through the provider's management path, since that path can be the thing that is degraded. 3. **Rehearsal, not documentation.** A mitigation nobody has executed is a hypothesis. Run it against the real dependency, on a schedule, including the escalation path: confirm who can open a case at the right severity at three in the morning, that the contact and entitlement are current, and that the identifiers you would attach are actually to hand. 4. **A written re-decision trigger.** State in advance what would make this tier the wrong home for this workload: a repeated class of incident nobody could diagnose, a needed control the tier will not expose, an exposure whose remediation date is never yours. Name the owner. Without a trigger, "we cannot see inside it" degrades into ambient discomfort that never becomes a decision. ## A register, not a policy document The artefact that survives contact with reality is a short table, one row per managed dependency: | Column | Why it is there | |---|---| | What evidence exists | Forces someone to check that the telemetry is real, not planned | | What mitigation exists, last rehearsed | Distinguishes a plan from a capability | | Cost of one opaque hour | Converts the argument into a number teams can compare | | Support entitlement and who can escalate | The thing nobody verifies until two in the morning | | Controls the tier will not expose | Where the next surprise will come from | The third row is the one that changes conversations. A store whose opaque hour costs almost nothing needs none of this ceremony; a payments ledger whose opaque hour is severe justifies duplicate paths, a stronger support entitlement, and possibly a different placement entirely. The register lets those two be treated differently by evidence rather than by seniority of the person arguing. ## Where a standard should say no, and where it should not A blanket ban on managed tiers is not a standard, it is a different and usually worse bet: it moves patching, backup verification and failover drills back onto your own engineers, who then do them less well than a provider doing them ten thousand times. The useful standard is narrower and conditional: - **No** for a workload that needs a control the tier will not expose, where the workaround is structural rather than local. That is a design fact, available before adoption. - **No** for a workload whose opaque hour is intolerable *and* which has no mitigation that works without a provider reply. The second clause is what makes this decidable; most such workloads become acceptable once the mitigation exists. - **Yes, with conditions** for the large middle: telemetry in place, a rehearsed mitigation, an entitlement matched to the impact, and a named owner for the re-decision. ## The second-order trade The deeper judgment is about where scarce operational attention goes. Managed tiers buy back the hours your engineers would spend on undifferentiated operations, and that is the return you are collecting. The failure mode is collecting it while still behaving as though you operate the thing: nobody instruments the client because "the provider has metrics", nobody rehearses a mitigation because "it is managed", and the first opaque incident finds an organisation with neither the provider's visibility nor its own. Spend a fraction of the hours you saved on the four requirements above, and the risk stops being unbounded and becomes merely priced.