Your dashboards are flat and green during a provider incident, yet customers report errors and the provider's status page says all clear — which signal do you trust?

## Two readings of a flat line Every time-series chart draws a gap and a zero almost identically, and the difference between them is the whole question. *The value is zero* means the measurement arrived and said nothing happened. *No value arrived* means the pipeline that carries measurements is broken and the chart is showing you its own silence. In normal operation the first reading is usually right, which is exactly why teams reach for it reflexively at the worst possible moment. During a platform-wide provider incident the second reading is far more likely, for a structural reason: **the telemetry ingestion path is itself a shared platform service**. It is operated by the provider, used by every tenant, and it shares the same underlying identity, name-resolution and network dependencies as the workloads it is measuring. It is not an independent observer. It is a participant in the same failure. ## Why the monitoring shares the failure Work through what a measurement has to do to reach a chart. An agent in the workload collects it, authenticates to the telemetry service with a platform credential, resolves that service's name, sends it over the platform network, and the service stores it for a query to find later. Every one of those steps is a dependency the incident may already have taken out. - If the platform's identity service is unavailable, the agent cannot authenticate and the measurement is dropped at the source. - If name resolution is degraded, the agent cannot find the ingestion endpoint. - If ingestion is degraded, the data is accepted and lost, or rejected outright. - If the query side is degraded, the data is safely stored and you cannot read it. The alerting built on those series inherits the whole chain. A rule that fires when errors exceed a threshold cannot fire on data that never arrived — its silence looks exactly like health. This is the single most dangerous property of the failure class: the instrument and the patient share a bloodstream. ## Ranking signals by independence The useful question in the first ten minutes is not *what does each signal say* but *what does each signal depend on*. | Signal | Depends on | What it can still tell you | |---|---|---| | Platform dashboards and alerts | The provider's telemetry ingestion, identity and network | Very little; its silence is uninformative | | Provider status page | The provider detecting, confirming and scoping first | Scope and duration, late | | Customer reports and support volume | Nothing you operate | That impact is real, with no detail | | A probe running outside the platform | Its own separate host and network | Whether your endpoint answers, right now | That ordering inverts the everyday one, and that inversion is the answer to the question. An engineer who has lived through this reaches for the least sophisticated signal first, because sophistication here is bought with dependencies. ## Telling blindness from health before it matters The distinguishing work is cheap and has to be done in advance: 1. **Emit a heartbeat series that is never zero.** A constant, always-present counter turns 'no data' into a detectable condition, because a gap in it cannot be explained as quiet traffic. 2. **Alert on staleness, not only on thresholds.** An alarm on *time since the last measurement arrived* fires precisely in the case a threshold alarm cannot cover. 3. **Run at least one probe outside the platform.** It must share no identity, no name resolution and no telemetry path with the target — otherwise it goes quiet in the same event and tells you nothing. 4. **Route the alert out of band.** An alerting channel that itself runs on the affected platform will deliver the page after the incident is over. A probe that only checks whether the endpoint answers, from somewhere entirely separate, is worth more during this incident than a wall of richly dimensioned charts, because it is the only thing in the room that is not also broken. ## What the green status page is worth Not much, in this window. Publishing is gated on the provider detecting the impact, confirming it, scoping which services and which regions are affected, and getting the post approved. The lag is structural rather than negligence, and pages are published per service and per region rather than per tenant, so a degradation touching a subset of tenants may never appear at all. The correct conclusion from a green page thirty minutes in is *almost nothing yet* — never *therefore we are fine*. Treat your own measured customer impact as the trigger, and use the page later for what it is genuinely good at: telling you the scope and the all-clear.