MONITOR  / field guide
Practitioner field guide · 2026-10-18

When the monitor shares the outage

Eleven public incidents, two Google-scale telemetry papers and the Prometheus Watchdog ecosystem, read for one question: what happens to the thing that tells you the system is broken when it is the system that is broken. A reader leaves able to draw the failure domains of their own monitoring, say who hears about silence, and run the drill that proves it.

40 primary and secondary sources 11 incidents 3 failure classes Evidence through October 2026 Read: 20 min
01

The territory

The monitor is a service with its own dependencies, and the evidence it fails is often its silence. Who has been bitten, how, and what this page leaves out.

73 h
Roblox outage, which the company attributes in part to telemetry that depended on the failing Consul
[4] 2021
2 min
Time to alert at Google Cloud in June 2019, followed by a debugging effort the post calls significantly hampered
[8] 2019
$20/mo
List price of an external heartbeat service for 100 jobs, the cheapest independent detector in the corpus
[37] as of 2026-10-18
>$300k/h
Self-reported hourly downtime cost for over 90% of mid-size and large firms in one 2024 survey
[40] 2024

State the problem without the tooling. A system fails. Some other system is supposed to notice, tell a human, and then help that human work out why. If the second system depends on the first for its data, its network, its name resolution, its credentials or its power, then the failure removes the observer in the same instant it creates the thing to be observed. The distinctive difficulty is that the observer's failure usually looks like good news: no alerts, a green page, a quiet pager.

The public record on this is better than the engineering-blog genre would suggest, because outages made the problem visible by accident. Facebook's October 2021 postmortem says the total loss of DNS "broke many of the internal tools we'd normally use to investigate and resolve outages like this" and that even out-of-band access was down [1]. Roblox lost 73 hours and names "a circular dependency between our telemetry systems and Consul" [4]. Slack's dashboarding and alerting service became unavailable while the team was triaging, so "all debugging and investigation was now hampered by the lack of our usual dashboards and alerts" [5]. Datadog's own March 2023 outage began with customer monitors "unavailable and not alerting" [7]. AWS could not update its Service Health Dashboard in 2020 because the posting tool used Cognito, which was itself affected [3].

I sort the thirteen cases here into three classes, and the sorting is mine; the postmortems do not use these names. Shared fate is a monitor that rides the same substrate as the product. Silent pipeline is a monitor whose own path fails without raising anything, because the only evidence of failure is an absence. Blind by design is a monitor that works exactly as built and measures the wrong layer. Each class has a different repair, and teams that fix only the first keep meeting the other two.

The surprise

The industry's settled answer to the silent pipeline, an always-firing Watchdog alert watched by an external receiver, is a one-line rule in the reference Prometheus stack [13], yet Alertmanager has no native heartbeat sender [16], the operator needed a feature request to ship one [17], and two pull requests that touched how the Watchdog is defined or labelled were closed unmerged [14] [15]. The most recommended safeguard in the field is still, in the reference implementation, an assembly exercise left to the operator.

Figure 1 · The landscape: eleven incidents, three failure classes

The observer
fails or lies

Class A: shared fate
Roblox, AWS 2020 and 2021,
Slack, Google 2019,
Facebook, Datadog

Class B: silent pipeline
GitLab 2017,
absent metrics,
frozen status page

Class C: blind by design
Firebase 2026,
Cloudflare 2023,
Cloudflare 2025

The observer
fails or lies

Class A: shared fate
Roblox, AWS 2020 and 2021,
Slack, Google 2019,
Facebook, Datadog

Class B: silent pipeline
GitLab 2017,
absent metrics,
frozen status page

Class C: blind by design
Firebase 2026,
Cloudflare 2023,
Cloudflare 2025

Shared fate is the most documented class; silent pipelines and blind-by-design signals are the ones a design review rarely asks about. Sources: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [27]. The classification is this guide's.
Diagram source

Scope. This guide covers the failure of the observer: telemetry, rule evaluation, paging, status pages and the tooling humans use during an incident. It does not cover choosing SLOs, alert fatigue, tracing, or vendor selection for monitoring in general, and it treats security monitoring only where the same dependency argument applies. Pricing is included for the independent pieces only.

02

How it is actually built

Three failure domains, a human response path that crosses them, and one component, the heartbeat receiver, whose only job is to treat silence as an event.

Strip the incidents of their brand names and the same shape is left. The product lives in one failure domain, and its shared dependencies (name resolution, identity, configuration, the network itself) sit underneath it. The telemetry plane, meaning collectors, a time-series store, rule evaluation and alert routing, is a second system, and the question in every postmortem above is whether it is a second failure domain or a tenant of the first. The third domain is the one almost nobody draws until after an incident: the components that live outside both, a heartbeat receiver, an external probe, the pager and the status page.

Figure 2 · Reference architecture: three failure domains and a heartbeat

C: outside both

B: telemetry

A: product

metrics

Watchdog, every 5 min

black box

silence pages a human

Services

Shared dependencies
DNS, auth, network, config

Collectors

Time series store

Rule evaluation

Alert routing

Heartbeat receiver

External probe

Status page and pager

C: outside both

B: telemetry

A: product

metrics

Watchdog, every 5 min

black box

silence pages a human

Services

Shared dependencies
DNS, auth, network, config

Collectors

Time series store

Rule evaluation

Alert routing

Heartbeat receiver

External probe

Status page and pager

The Watchdog is evaluated inside the telemetry plane but received outside it, so silence from domain B pages a human through domain C. Reconstructed from [13] [22] [19] [20] [31]; the dashed edge from shared dependencies to collectors is the failure path in Roblox [4] and AWS 2021 [2].
Diagram source

A telemetry store built to outlive its subject

Both Google and Facebook designed their time-series stores around the incident rather than the steady state. Monarch trades consistency for availability because blocking on Spanner "would increase mean-time-to-detection and mean-time-to-mitigation" [31]. Gorilla states "High availability trumps resource efficiency" and keeps two in-memory copies so the store can withstand a regional disaster [32]. Both accept lossy data on the write path as the price of being up.

Runs this way at: Google [31], Facebook [32]

A watcher pinned to an older version

Monarch has three production deployments. The third, "meta", runs "a proven-stable older version of Monarch and monitors all other Monarch deployments" [31]. Nobody says why the meta tier is old rather than large; I read it as removing the most common shared fate between watcher and watched, which is the same release. That is an inference.

Runs this way at: Google [31]

A separate instance for telemetry about the telemetry

Grafana's Loki documentation says to collect data about Loki "in a separate instance of Loki, Prometheus, and Grafana" so a broken cluster can be troubleshot "from a working one" [20]. Its Mimir page names the practice meta-monitoring without requiring separation [21], which is a small example of how the advice drifts between sibling products.

Runs this way at: Grafana documentation [20] [21]

The Watchdog and the receiver of its absence

The kube-prometheus rule is vector(1), "always firing", labelled severity none, and its text sends the reader to a mechanism that notifies "when this alert is not firing" [13]. The runbook names the DeadMansSnitch integration in PagerDuty [22]; Nanit describes the same idea as a vigilance control [28]; the Prometheus project's own guidance asks for an end-to-end blackbox test of the alert path from outside [19].

Runs this way at: kube-prometheus [13], Nanit [28]

A fallback with fewer dependencies

When Cognito was affected, AWS posted dashboard updates with "a backup tool that had fewer dependencies, though it was slower and less familiar to support operators" (retrieved summary) [3]. Python moved its status page's DNS to a different provider after its 2016 outage [12]. Both are the same move: shrink the dependency list of the thing humans use when everything else is down.

Runs this way at: AWS [3], Python [12]

Meta-monitoring as code, per stage

Mercari built a Terraform module for each step of the flow it wanted to observe, so each stage of the pipeline has an alert policy rather than the pipeline having one global health indicator [24]. Stile's SREcon talk generates absent-alerts for every metric the team expects to exist, because otherwise alerts "aren't going to fire and you won't know that they've gone away" [35].

Runs this way at: Mercari [24], Stile [35]

The human response path deserves its own line in the diagram because it is where Facebook and Google lost time. Facebook's tools broke because DNS broke [1]; Google's tools "compet[ed] over use of the now-congested network" [8]. In neither case was the telemetry the problem. The detection worked (Google was alerted "two minutes after it began"), and the diagnosis stalled because the tools a person needs to follow an alert, a shell, a ticket, a runbook, a chat room, travel on the network that failed.

Figure 3 · The failure path: detected from outside, then blind

On-callExternal monitorDashboards andalertingProductUsersOn-callExternal monitorDashboards andalertingProductUserstriage by logs andguesseserrors beginshared substrate degradespage, error rates risingopen dashboardsunavailableremediate without a picture
On-callExternal monitorDashboards andalertingProductUsersOn-callExternal monitorDashboards andalertingProductUserstriage by logs andguesseserrors beginshared substrate degradespage, error rates risingopen dashboardsunavailableremediate without a picture
The pattern in Slack's January 2021 account: an external monitor paged first, then the internal dashboards and alerting disappeared. Reconstructed from [5]; the same order of events, with different mechanisms, appears in [2] [8].
Diagram source
03

The decisions that matter

Five forks. For each: what the sources chose, what they rejected, and the condition under which the rejected option becomes right.

A caution about the evidence before the decisions. These are not five ADRs. No organisation in the corpus published a record that says "we considered X for the monitor and rejected it". The decisions below are reconstructed from postmortem remediations, documentation and issue threads, and each row says which. The conditions in the last column are mine, derived from the stated reasons.

Decision 1: where does telemetry about the system live?

Chosen
  • A separate instance or failure domain from the system, as Loki's documentation recommends [20]
  • A store designed to stay writable during the incident, lossy if it must be [31] [32]
Rejected
  • Telemetry in the same cluster, region or mesh as the product: Roblox's telemetry depended on Consul [4], AWS 2021 monitoring data shared the congested network [2]
  • Excluding telemetry from the HA tier to save cost: Cloudflare's logging was intentionally outside it, and raw logs were unavailable to most customers throughout [6]
Flips when
  • The product is small enough that a second stack costs more than the outage it covers, in which case buy an external probe instead.
  • The separate instance has no owner. Then it fails silently and you have built Class B.

Decision 2: who notices when the monitor goes silent?

Chosen
  • An always-firing Watchdog evaluated inside and received outside, by a heartbeat service [13] [22]
  • A rule that fires when an expected metric is absent, per metric [35]
Rejected
  • The monitor checking itself: "A Prometheus server cannot evaluate its own alert rules while it is stopped" [25]
  • A watcher of watchers, which Nanit replaced because the design contained a single point of failure [28]
Flips when
  • The watcher is a second independent monitor on a different provider run by different people, as the Conf42 talk argues [36]; that is a vendor's advice and doubles the monitoring bill.
  • The heartbeat receiver is not itself reliable or loud: alerta's UI did not show expired heartbeats [18]

Decision 3: what should the Watchdog prove?

Chosen
  • Alertmanager-to-receiver liveness, the minimal and unambiguous reading, vector(1), shipped in kube-prometheus [13]
Rejected
  • A Watchdog that also goes quiet when the time-series store is stale: one PR argued for changing what it measures, was closed unmerged the day it opened, and a maintainer asked for the expression to be configurable in the chart [14]
  • Per-alert labels to route the Watchdog to its own receiver: proposed and closed unmerged, with the code-owner reviews never given [15]
Flips when
  • Your pipeline has stages that can fail independently (collector, store, rules, routing). Then one Watchdog proves only the last stage, and you want one check per stage, as Mercari did [24].
  • The project has not published a reason for either closure, so whether the minimal reading is a principle or a default is open.

Decision 4: where does the status page live, and what may it be trusted to say?

Chosen
  • A different DNS provider and domain, as Python moved to after 2016 [12]
  • Hosting off the product's platform, as Cloudflare's page was in 2025 [10]
Rejected
  • Same-platform hosting, which StatusPal's vendor advice calls out; note the claim about Facebook is the vendor's own inference [29]
  • Status derived from server-side health alone: the Firebase and Google Ads dashboards stayed green through a client-side SDK failure [11]
Flips when
  • The page is updated by a scheduled job. A frozen page "does not look broken" [27], so stamp every status with when it was last asserted.
  • Independence breaks the diagnostic: Cloudflare's independent page went down coincidentally and the team first read it as an attack [10].

Decision 5: what does the on-call use when the normal tools are gone?

Chosen
  • A break-glass tool with fewer dependencies, slower and less familiar by design [3]
  • Out-of-band access, assumed independent: Facebook had it and lost it too [1]
Rejected
  • Reliance on the standard dashboard stack and chat for diagnosis, which hampered Slack and Google [5] [8]
Flips when
  • The break-glass tool is not exercised. Then the first use is during an incident, and its unfamiliarity is the cost AWS noted [3]. Google's own paper adds that out-of-band networks fail with significant impact [33].
DecisionChosenRejectedBecauseEvidence
Telemetry locationSeparate instance, availability-first storeSame cluster or HA exclusionShared substrate removes sight at the worst time[20] [4] [2] [6]
Detector of silenceExternal heartbeat receiverSelf-check, watcher of watchersA stopped evaluator cannot report itself[13] [25] [28]
What Watchdog provesOpen question in the chartSingle-stage proofStages fail independently[14] [15] [24]
Status pageSeparate DNS, off-platform, timestampedSame platform, server-side onlyShared fate; wrong witness[12] [10] [11] [27]
Response toolingFewer-dependency fallbackStandard stack onlyTools degrade with the network[3] [8] [5]

Figure 4 · Four questions that decide how much monitoring independence you need

yes

no

no

yes

yes

no

no

yes

Monitor shares a
dependency with product?

Move it, or make an external
heartbeat the detector

Does a human hear
when the monitor goes silent?

Add Watchdog plus an
external receiver

On-call path needs the
same DNS, SSO, network?

Build a break-glass path
with fewer dependencies

Monitor killed on
purpose this year?

Schedule the drill

Repeat after each platform change

yes

no

no

yes

yes

no

no

yes

Monitor shares a
dependency with product?

Move it, or make an external
heartbeat the detector

Does a human hear
when the monitor goes silent?

Add Watchdog plus an
external receiver

On-call path needs the
same DNS, SSO, network?

Build a break-glass path
with fewer dependencies

Monitor killed on
purpose this year?

Schedule the drill

Repeat after each platform change

The questions run from cheapest to most expensive; most teams answer the first two in the negative. Derived from the decisions above; no source publishes this tree.
Diagram source
04

What broke in production

Eleven incidents and two smaller cases, grouped by failure class. The design rule in each is this guide's reading of the postmortem's own remediation.

Class A: shared fate

Postmortem

AWS US-EAST-1, 7 December 2021

AssumptionOperators would still see real-time monitoring data if a capacity scaling activity went wrong.
What happenedAn automated scaling activity at 7:30 AM PST caused congestion on the devices connecting two networks; "This congestion immediately impacted the availability of real-time monitoring data for our internal operations teams" and impaired the Service Health Dashboard, which could not fail over to its standby region as intended [2].
Blast radiusCongestion significantly improved by 1:34 PM and all devices recovered by 2:22 PM PST, so about 6 h 52 m from trigger (derived). Some CloudWatch data was never captured.
FixNot itemised for the monitoring path in the summary I fetched; the dashboard's failover is the stated gap.
Design ruleTest your status dashboard's failover while healthy, and log the data operators actually used when the monitoring was down.
Source[2]
Postmortem

AWS Kinesis, 25 November 2020

AssumptionCloudWatch and the status tooling were independent enough of the service that failed.
What happenedKinesis front-end servers exceeded an OS thread limit; CloudWatch alarms went to INSUFFICIENT_DATA; the dashboard posting tool used Cognito, which was impaired, so updates went out through a backup tool with fewer dependencies [3].
Blast radiusCloudWatch impact began at 5:15 AM PST and metrics and alarms fully recovered by 10:31 PM PST, roughly 17 h 16 m (derived).
FixThe backup tool existed; the report describes it as slower and less familiar to operators.
Design ruleDraw the dependency graph of the status tooling, not only the product, and rehearse the fallback.
Source[3]
Postmortem

Roblox, 28 to 31 October 2021

AssumptionTelemetry and the service-discovery layer it ran on could be diagnosed independently.
What happenedMonitoring tools "relied on affected systems, such as Consul"; the post names a circular dependency between telemetry and Consul that "severely hampered the triage process" [4].
Blast radius"The outage lasted 73 hours." The post links the length to diagnostic difficulty.
FixNot enumerated in the fetched excerpt; see the full post.
Design ruleA dependency edge from telemetry to the control plane it observes is a defect even if it has never fired.
Source[4]
Postmortem

Slack, 4 January 2021

AssumptionThe dashboards and alerting service would be available during triage.
What happenedAn external monitoring service paged on rising error rates; then Slack's dashboarding and alerting became unavailable, which the post attributes to services "running in a different VPC from their backend databases" [5].
Blast radiusSlack was degraded rather than down by about 9:15 AM PST and the network returned to normal by 10:40 AM PST after a Transit Gateway capacity increase.
FixMonitoring team paged in to restore the service; remediation specifics are in the post.
Design ruleCredit the external probe: it was the only detector that survived. Keep one.
Source[5]
Postmortem

Google Cloud networking, 2 June 2019

AssumptionTools used to debug a network failure would not compete with the failing network.
What happenedTwo benign misconfigurations and a software bug removed network control capacity; "Debugging the problem was significantly hampered by failure of tools competing over use of the now-congested network" [8].
Blast radiusBetween 3 h 19 m and 4 h 25 m of impact. Engineers were alerted two minutes after the failure began.
FixNot itemised in the excerpt I fetched.
Design ruleFast detection with slow diagnosis is a tooling-placement bug. Put investigation tools on a protected traffic class.
Source[8]
Postmortem

Facebook, 4 October 2021

AssumptionOut-of-band access and internal tools would survive a backbone failure.
What happenedDNS servers became unreachable even though they were operational; "Our primary and out-of-band network access was down", and the loss of DNS broke many internal tools used to investigate [1].
Blast radiusGlobal; I did not capture a duration from the post, so none is stated here.
FixThe post describes hardening and an audit tool bug; it does not itemise a monitoring change in the excerpt.
Design ruleInventory what the on-call needs to even open the incident, then ask what each item depends on.
Source[1]
Postmortem

Datadog, 8 to 10 March 2023

AssumptionA security update applied automatically to VMs would be safe at fleet scale.
What happenedsystemd-networkd "forcibly deleted the routes managed by the Container Network Interface (CNI) plugin", taking nodes offline across the US1, EU1, US3, US4 and US5 regions; early on, monitors were "unavailable and not alerting" [7].
Blast radiusFrom 06:03 UTC on 8 March to 06:25 UTC on 10 March for full resolution including backfill, about 48 h 22 m (derived).
FixThe post describes remediation of the update path; I did not capture its details.
Design ruleIf your monitoring is a vendor, your detector of vendor failure must be another party. A Watchdog sent to a different vendor does this for free.
Source[7]

Class B: silent pipeline

Postmortem

GitLab, 31 January 2017

AssumptionNotification emails from failing backup jobs would be seen.
What happenedBackups "failed silently" because the job used PostgreSQL 9.2 against a 9.6 server; the failure emails were rejected because DMARC was not enabled for them, so "there was no indication of failure" [9].
Blast radiusNo usable pg_dump backup when it was needed; several other recovery techniques also did not work as assumed.
FixPrometheus monitoring for backups and a public backup dashboard were listed as follow-up work.
Design ruleAlert on the absence of a success signal, never only on the presence of a failure message.
Source[9]
Talk

Absent metrics at Stile, SREcon21

AssumptionAn alert on a metric would fire if the thing went wrong.
What happened"Your Prometheus alerts aren't going to fire and you won't know that they've gone away." The team found metrics that were not actually being exported [35].
Blast radiusNot a single incident; a class of latent blind spots. Video timestamp not verified.
FixGenerated absent-alerts for expected metrics; initialise counters at start-up.
Design ruleEvery alert needs a companion that fires when its own input disappears.
Source[35]
Eng blog

A status page that froze for four days

AssumptionA scheduled job updates the page; if it fails we will see a red page.
What happenedCI minutes ran out; every scheduled run "died in about three seconds with no runner and no logs"; "The monitor was watching the wrapper" [27].
Blast radiusFour days of stale status at a small team. This is a single practitioner's anecdote and is included for its clarity.
FixNot itemised in the part I read.
Design ruleA status without an assertion time is not a status. Show 'last checked' on every indicator.
Source[27]

Class C: blind by design

Postmortem

Cloudflare, 2 to 4 November 2023

AssumptionObservability would detect a loss of utility power, and logging could sit outside the HA cluster.
What happened"None of our observability tools were able to detect that the source of power had changed." Logging was "intentionally not part of the high availability cluster" and the raw log services were unavailable for most customers for the duration [6].
Blast radiusFrom 11:43 UTC on 2 November to 04:25 UTC on 4 November, about 40 h 42 m (derived).
FixThe post commits to reducing dependence on one facility; see the full text.
Design ruleA tier you exclude from HA to save money is a tier you will not have during the incident you bought HA for.
Source[6]
Eng blog

Firebase and Google Ads status dashboards, 2026

AssumptionServer-side health metrics describe user-visible health.
What happenedA client-side SDK failure left the dashboards green: "Because these dashboards rely primarily on server-side health metrics, they did not register client-side SDK crashes" (secondary account quoting Google) [11].
Blast radiusGlobal for affected SDK users; I did not read Google's own postmortem, only the newsletter's quotation.
FixThe newsletter reports poor response; remediation details are in Google's text.
Design ruleA green dashboard is a statement about its input layer. Name the layer on the page.
Source[11]
Postmortem

Cloudflare, 18 November 2025

AssumptionA status page hosted off the platform is a clean signal.
What happened"Cloudflare's status page went down", off-platform, at the same time as the incident; the team first read the pattern as an attack, and debugging and observability systems consumed large amounts of CPU [10].
Blast radiusSee the post; I record only the monitoring-relevant facts.
FixNot captured in this guide.
Design ruleIndependence removes shared fate and adds coincidence. Do not let the state of the status page be evidence of cause.
Source[10]
What is missing

No incident in this corpus credits a dead man's switch with catching a monitoring outage. The nearest case is Slack, where an external monitor paged first [5], but that monitor watched the product, not the telemetry plane. Either the pattern works quietly and nobody writes it up, or it is rarely deployed. The public record cannot separate those readings, and that is the reader's risk.

05

Numbers you can plan against

Durations from the postmortems, prices from vendor pages fetched on 18 October 2026, and one derived comparison with its arithmetic shown.

MetricValueAtContextAs ofSource
Outage duration73 hRobloxTelemetry/Consul circular dependency2021[4]
Time to alert2 minGoogle CloudNetwork control failure2019[8]
Incident duration3 h 19 m to 4 h 25 mGoogle CloudSame incident2019[8]
Incident duration6 h 52 m (derived)AWS7:30 AM to 2:22 PM PST, 7 Dec 20212021[2]
CloudWatch impact17 h 16 m (derived)AWS5:15 AM to 10:31 PM PST, 25 Nov 20202020[3]
Incident duration48 h 22 m (derived)Datadog06:03 UTC 8 Mar to 06:25 UTC 10 Mar2023[7]
Incident duration40 h 42 m (derived)Cloudflare11:43 UTC 2 Nov to 04:25 UTC 4 Nov2023[6]
Heartbeat service$0 / $20 / $80 per monthHealthchecks.io20 / 100 / 1,000 jobs2026-10-18[37]
Heartbeat add-on$20 per month per 10Better Stack10 included; about $2 each beyond (derived)2026-10-18[38]
Status page add-on$15 per monthBetter StackOne included2026-10-18[38]
Hosted status page$29 to $1,499 per monthAtlassian StatuspageHobby to Enterprise2026-10-18[39]
Downtime cost>$300,000 per hourITIC surveyOver 90% of mid-size and large firms, self-reported2024[40]

The comparison that matters is lopsided enough that its precision does not. A Business-tier heartbeat plan is $20 per month, or $240 a year ($20 times 12). The ITIC survey's floor for most mid-size and large firms is $300,000 for a single hour of downtime. Dividing, $300,000 by $240 is 1,250, so one hour at that floor pays for 1,250 years of the independent detector. Two caveats keep this honest: the survey is self-reported and measures downtime of the product, not the marginal cost of detecting it late, and the detector only helps if its alert reaches a person who can act. The cost of the detector is not the money; it is the routing, the on-call ownership and the quarterly drill.

Three things nobody has published. First, how often the external heartbeat receivers themselves fail or are misconfigured; the one data point is alerta's UI hiding expired heartbeats [18]. Second, the false-positive rate of Watchdog-absence pages, which determines whether anyone trusts them. Third, any measured mean-time-to-detect for a telemetry-plane outage with and without an external detector. The Microsoft study [34] establishes that detection gaps matter at hyperscale, but I did not take a figure from it.

Read these carefully

Prices come from vendor pages that carry no date; the as-of date is the day I fetched them. The Statuspage figures came from a summarised fetch and are not verbatim. Durations marked derived are my subtraction from the timestamps each post gives, and use the post's own time zone. The ITIC figure is a self-reported survey band.

06

The evidence wall

Every source behind this page, graded. Filter by kind. Gaps are stated rather than hidden: two talk timestamps could not be verified, several vendor pages are undated, and the Firebase account is secondary.

PostmortemMeta (Facebook)2021-10-05

[1] More details about the October 4 outage

The backbone withdrawal made DNS servers unreachable, and the loss of DNS broke the internal tools used to investigate; primary and out-of-band network access were both down.

Carry forwardList what the on-call needs to open an incident (DNS, auth, network, door badges) and put each on a path that does not share the failure.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
PostmortemAWS2021-12-10

[2] Summary of the AWS Service Event in the N. Virginia (US-EAST-1) Region

Internal network congestion on 7 December 2021 degraded real-time monitoring data for operators, delayed CloudWatch and impaired the Service Health Dashboard, which could not fail over to its standby region as intended.

Carry forwardA health dashboard and its failover path are part of the monitored estate; test the failover while the region is healthy.
https://aws.amazon.com/message/12721/
PostmortemAWS2020-11-25

[3] Summary of the Amazon Kinesis Event in the Northern Virginia (US-EAST-1) Region

Kinesis failure took CloudWatch metrics and alarms into INSUFFICIENT_DATA, and the Service Health Dashboard could not be updated because its posting tool used Cognito, which depended on Kinesis; a backup tool with fewer dependencies was used instead.

Carry forwardDependency graphs of the status tooling matter as much as those of the product; keep a boring fallback with fewer dependencies.
https://aws.amazon.com/message/11201/
PostmortemRoblox2022-01 (event 2021-10-28 to 10-31)

[4] Return to Service 10/28-10/31 2021

A 73-hour outage during which telemetry relied on the failing Consul, a circular dependency the company says severely hampered triage.

Carry forwardMap telemetry's dependencies against the control plane it observes; a loop between the two removes sight exactly when needed.
https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021
PostmortemSlack2021-01 (event 2021-01-04)

[5] Slack's Outage on January 4th 2021

An external monitoring service paged first; then the dashboarding and alerting service became unavailable during triage, hampering investigation.

Carry forwardAn external check detected it; the internal dashboards did not survive it. Credit the external probe, and rehearse debugging without dashboards.
https://slack.engineering/slacks-outage-on-january-4th-2021/
PostmortemCloudflare2023-11 (event 2023-11-02 to 11-04)

[6] Post mortem on Cloudflare Control Plane and Analytics Outage

A data-centre power failure removed the logging and analytics cluster that was deliberately outside the HA cluster; observability tools did not detect that the power source had changed.

Carry forwardExcluding telemetry from the HA tier is a decision with a price: raw logs were unavailable for most customers for the duration.
https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
PostmortemDatadog2023-03 (event 2023-03-08 to 03-10)

[7] Multiregion infrastructure connectivity issue

A systemd update applied automatically deleted CNI routes across five regions; at the start of the outage customer monitors were unavailable and not alerting.

Carry forwardWhen the monitoring vendor fails, customers' alerts fail silently; an independent heartbeat outside the vendor is the only detector.
https://www.datadoghq.com/blog/2023-03-08-multiregion-infrastructure-connectivity-issue/
PostmortemGoogle Cloud2019-06 (event 2019-06-02)

[8] Google Cloud Networking Incident #19009

Engineers were alerted two minutes after the failure began, but debugging was hampered by tools competing for the congested network.

Carry forwardFast detection is not fast diagnosis; run the investigation tooling on a network class that stays uncongested.
https://status.cloud.google.com/incident/cloud-networking/19009
PostmortemGitLab2017-02 (event 2017-01-31)

[9] Postmortem of database outage of January 31

Backup jobs failed silently on a version mismatch, and failure notification emails were rejected for missing DMARC, leaving no indication of failure.

Carry forwardA notifier with a single channel and no delivery check is a monitor that can fail silently; alert on the absence of success, not on the presence of failure.
https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/
PostmortemCloudflare2025-11-18

[10] Cloudflare outage on November 18, 2025

The status page, hosted off Cloudflare, went down at the same time as the incident; the team initially read the pattern as an attack. Debugging and observability systems consumed large amounts of CPU.

Carry forwardIndependence of a status page removes shared fate but can add a misleading coincidence; do not treat its state as evidence about the cause.
https://blog.cloudflare.com/18-november-2025-outage/
Eng blogThe Pragmatic Engineer (quoting Google)2026-10-08

[11] The Pulse: Firebase's global outage & poor response

Secondary account quoting Google's postmortem: the Firebase and Google Ads status dashboards stayed green because they relied on server-side health metrics and did not register client-side SDK crashes.

Carry forwardGreen dashboards describe the layer being measured. If the failure lives in the client, server-side health is the wrong witness.
https://blog.pragmaticengineer.com/the-pulse-firebases-global-outage-poor-response/
PostmortemPython Software Foundation2016-10-21

[12] Infrastructure postmortem: DNS outage

The status page resolved from the same DNS provider as python.org; the team committed to run DNS from a different provider for incidents like this.

Carry forwardThe cheapest independence you can buy is a different DNS provider and domain for the page that tells users you are down.
https://status.python.org/incidents/x97mmj5rqs5f
Source codeprometheus-operator/kube-prometheusmain branch (undated)

[13] kubePrometheus-prometheusRule.yaml: the Watchdog alert

The shipped Watchdog rule has expression vector(1), severity none, and a description that sends the reader to an external notification mechanism for the absence of the alert.

Carry forwardThe in-product part of a dead man's switch is one line; everything that matters is the receiver outside the cluster.
https://github.com/prometheus-operator/kube-prometheus/blob/main/manifests/kubePrometheus-prometheusRule.yaml
Source codeprometheus-community/helm-charts2024-07-29

[14] PR #4753 [kube-prometheus-stack] Improve watchdog alert (closed, not merged)

A proposal to change what the Watchdog expression measures was opened and closed by its author the same day; a maintainer asked for the expression to be configurable in the chart and mirrored in the hack scripts. No maintainer reason for closing is on the page.

Carry forward'Alive' is contested: Alertmanager-only liveness and whole-stack liveness are different tests, and the project has no settled answer in the chart.
https://github.com/prometheus-community/helm-charts/pull/4753
Source codeprometheus-community/helm-charts2023-11-23

[15] PR #4037 [kube-prometheus-stack] allow setting labels per Alert (closed, not merged)

A PR to let a single alert carry its own labels, motivated by labelling Watchdog with heartbeat: true for routing, was closed by its author on 2023-12-19 with all seven code-owner reviews still awaiting.

Carry forwardRouting the heartbeat to a different receiver needs a per-alert label; the unreviewed PR shows how thin the maintainer attention to this path was.
https://github.com/prometheus-community/helm-charts/pull/4037
Source codeprometheus/alertmanager2020-10-29

[16] Issue #2407 Feature request: support GET for webhook receiver (closed as completed 2020-11-12)

A user wanting a dead man's switch asked Alertmanager to send periodic heartbeats; a maintainer said switching the webhook to GET does not make sense.

Carry forwardAlertmanager has no native heartbeat sender; users bolt on external heartbeat services.
https://github.com/prometheus/alertmanager/issues/2407
Source codeprometheus-operator/prometheus-operator2021-04-09

[17] Issue #3970 Support OpsGenie Heartbeat (closed 2021-09-06 via PR #4110)

The operator needed explicit support to ship the Watchdog to an OpsGenie heartbeat; the issue names the feature as 'also known as Watchdog/DeadManSwitch in other platforms'.

Carry forwardThe pattern exists under three names in three tools; search all three.
https://github.com/prometheus-operator/prometheus-operator/issues/3970
Source codealerta/alerta2019-11-07

[18] Issue #1110 Improve Prometheus Heartbeat handling (DeadMansSwitch) (closed 2020-06-07)

The receiving side had its own gap: the web UI did not indicate expired heartbeats.

Carry forwardThe watcher of the watcher needs a visible, loud failure mode; an expired heartbeat that renders as nothing reproduces the original problem.
https://github.com/alerta/alerta/issues/1110
Design / ops docPrometheus projectundated

[19] Alerting practices: Metamonitoring

The project's guidance opens its metamonitoring section by asking for confidence that monitoring works, and recommends external blackbox monitoring as a fallback (retrieved paraphrase plus fragments).

Carry forwardCombine up-checks on every monitoring component with one end-to-end test of the alert path from outside.
https://prometheus.io/docs/practices/alerting/
Design / ops docGrafana Labs (Loki docs)undated

[20] Meta monitoring (Loki operations)

Grafana's guidance for Loki: collect data about Loki in a separate instance of Loki, Prometheus and Grafana, so a broken cluster can be diagnosed from a working one.

Carry forwardA separate instance is the product vendor's default recommendation, not an exotic hardening step.
https://grafana.com/docs/loki/latest/operations/meta-monitoring/
Design / ops docPrometheus Operator communityundated

[22] Runbook: Watchdog

The runbook says the Watchdog alert exists to ensure the entire alerting pipeline is functional and recommends an external integration that notifies when it stops firing, naming DeadMansSnitch in PagerDuty.

Carry forwardMake the 'not firing' notification an external integration, not another internal rule.
https://runbooks.prometheus-operator.dev/runbooks/general/watchdog/
Eng blogGoogle2016

[23] Site Reliability Engineering, chapter 6: Monitoring Distributed Systems

Page on symptoms, and ask that the elements of the monitoring system that direct to a pager be very simple and robust.

Carry forwardThe paging path is the part of the monitor that must be simplest; keep cause-oriented checks out of it.
https://sre.google/sre-book/monitoring-distributed-systems/
VendorOneUptime2026-07-31

[25] Monitor Prometheus So Its Failure Cannot Silence Host-Down Alerts

Vendor blog stating that a stopped Prometheus cannot evaluate its own rules and that the prober must sit outside the failure domain.

Carry forwardState the rule in one sentence: the observer of the observer must not share its failure domain.
https://oneuptime.com/blog/post/2026-07-31-monitor-prometheus-server-out-of-band/view
Eng blogharuodev (DEV Community)undated (Sep 8)

[27] Our status page froze for four days because the CI minutes ran out

A small-scale anecdote: a scheduled CI job updating the status page died for four days with no runner and no logs; a frozen status page does not look broken.

Carry forwardA stale 'all green' is a failure mode; stamp every status with the time it was last asserted.
https://dev.to/haruodev/our-status-page-froze-for-four-days-because-the-ci-minutes-ran-out-1m37
Eng blogInfoQ (Nanit)2022-05-19

[28] Nanit replaces monitoring-of-monitoring with a Dead Man's Switch (InfoQ news)

News write-up of Nanit's switch from a watcher-of-watchers to a vigilance control; the old setup contained a single point of failure.

Carry forwardWatchers of watchers recurse; a heartbeat ends the recursion at an external receiver.
https://www.infoq.com/news/2022/05/monitoring-monitoring/
VendorStatusPal2021-04-09

[29] Learning from Facebook: Keep your Status Page Separately from your Infrastructure

Vendor advice: never host the status page within your own infrastructure; if self-hosting, use separate infrastructure, data centre, hosting provider and domain. The claim about Facebook's setup is the vendor's inference.

Carry forwardTreat as advice from someone who sells the fix.
https://statuspal.io/blog/2021-04-09-learning-from-facebook-keep-your-status-page-separately-from-your-infrastructure
PaperGoogle (Adams et al.)2020-08

[31] Monarch: Google's Planet-Scale In-Memory Time Series Database (PVLDB 13(12))

Monarch trades consistency for availability because blocking on Spanner would raise mean-time-to-detection; it has an internal, an external and a 'meta' deployment, the meta running a proven-stable older version that monitors all other Monarch deployments.

Carry forwardGoogle's own monitor is watched by a deliberately conservative, older copy of itself: the meta tier is a pinned version, not a bigger cluster.
https://www.vldb.org/pvldb/vol13/p3181-adams.pdf
PaperFacebook (Pelkonen et al.)2015-09

[32] Gorilla: A Fast, Scalable, In-Memory Time Series Database (PVLDB 8(12))

Facebook's telemetry store sets availability above efficiency: two redundant in-memory copies and survival of whole-region loss, at the price of possibly dropping small amounts of data on the write path.

Carry forwardDesign the telemetry store to be writable during the incident, and accept lossy data.
https://www.vldb.org/pvldb/vol8/p1816-teller.pdf
PaperGoogle (Govindan et al.)2016-08

[33] Evolve or Die: High-Availability Design Principles Drawn from Google's Network Infrastructure (SIGCOMM 2016)

An out-of-band control network is not immune: its failures have significant impact; monitoring coverage gaps and collector placement hamper visibility.

Carry forwardAn out-of-band path needs its own monitoring; do not assume independence, measure it.
https://homepages.dcc.ufmg.br/~cunha/teaching/20221/cloudcomp/readings/03-readings/govindan16evolve.pdf
PaperMicrosoft (Parayil et al.)2023-12

[34] Detection Is Better Than Cure: A Cloud Incidents Perspective (ESEC/FSE 2023)

A study of a year of Microsoft incidents on monitoring gaps and detection delay; generic evidence, no figure taken here.

Carry forwardDetection gaps are a measured class of incident at hyperscale.
https://www.microsoft.com/en-us/research/?p=990273
TalkStile Education (Nick Spain)2021-10-13

[35] Watching the Watchers: Generating Absent Alerts for Prometheus (SREcon21)

Alerts that depend on a metric go silent when the metric disappears; the talk generates 'absent' alerts for metrics expected to exist. Slide text: 'We found metrics that weren't actually being exported'. Video timestamp not verified; claims rest on the session abstract and slide text.

Carry forwardEvery alert needs a companion that fires when its input vanishes.
https://www.usenix.org/conference/srecon21/presentation/spain
VendorHealthchecks.io2026-10-18 (fetched; page undated)

[37] Pricing

Heartbeat monitoring price points: Hobbyist $0 per month (20 jobs), Business $20 (100 jobs), Business Plus $80 (1,000 jobs).

Carry forwardAn external dead man's switch costs less than one engineer-lunch per month.
https://healthchecks.io/pricing/
VendorBetter Stack2026-10-18 (fetched; page undated)

[38] Pricing

Add-ons: 10 monitors and 10 heartbeats and 1 status page included; 10 more heartbeats $20 per month; an additional status page $15 per month.

Carry forwardHeartbeats and status pages are priced as small add-ons, separately from the monitoring bill.
https://betterstack.com/pricing
VendorAtlassian2026-10-18 (fetched; page undated)

[39] Statuspage pricing

Public-page tiers per month: Free, Hobby $29, Startup $99, Business $399, Enterprise $1,499 (from a summarised fetch, not verbatim).

Carry forwardStatus-page hosting runs from free to roughly $1,500 per month depending on subscribers.
https://www.atlassian.com/software/statuspage/pricing
07

Build a miniature, then productionise it

Six rungs. The line between toy and real is rung four, where the receiver moves out of your laptop.

Run Prometheus and Alertmanager locally with a Watchdog

Compose file with Prometheus, Alertmanager and the kube-prometheus Watchdog rule (vector(1), severity none), routed to a local webhook that logs each delivery.

Done when: the webhook log shows a delivery at the repeat interval.  Teaches: what the alert pipeline emits when everything is fine.

Kill each stage and watch what you do not see

Stop Prometheus, then Alertmanager, then the receiver, one at a time. Write down which stops produce a page and which produce silence.

Done when: you have a table of stage, symptom, and whether a human was told.  Teaches: which failures are loud and which are silent, in your own stack.

Add the absence detector

Point the webhook at an external heartbeat service (Healthchecks has a free tier) with a grace period of three repeat intervals. Repeat rung two.

Done when: stopping any stage produces a page from outside your laptop.  Teaches: how silence becomes a signal, and what the grace period costs in detection time.

Add per-input absent alerts

For every alert, add a companion using absent() or a freshness check on the exported metric, and initialise counters at start-up.

Done when: removing an exporter produces a named alert, not a quiet dashboard.  Teaches: the Stile lesson: an alert is only as alive as its input.

Draw the dependency graph of the response path

List what the on-call needs from alert to fix: the pager, VPN or SSO, DNS, chat, the runbook host, the shell. Mark every shared dependency with the product.

Done when: each shared dependency has a documented alternative or an accepted risk.  Teaches: the Facebook and Google lesson: detection and diagnosis are different systems.

Run the game day and the quarterly drill

Partition the telemetry plane from the product in a staging environment and run an incident with the monitoring dark. Time to first correct hypothesis is the metric. Repeat after every platform change.

Done when: the drill is on the calendar and its result changed at least one dependency.  Teaches: that independence decays unless it is tested.

08

Keep hunting

Two searches were run as written; the rest are built from vocabulary the sources taught and were used by the research agents or are suggested next steps. The page marks which is which.

Run in this hunt

  • Alertmanager "dead man's switch" OR "DeadMansSwitch" issue watchdog heartbeat alert pipeline github prometheus
  • postmortem monitoring system down during incident "we were blind" OR "flying blind" observability dependent on same infrastructure

Vocabulary the sources taught (use these next)

  • "dead man's switch" OR watchdog OR heartbeat OR "vigilance control" alerting pipeline
  • "meta-monitoring" OR "metamonitoring" OR "monitoring the monitoring"
  • "circular dependency" telemetry postmortem
  • "status page" "same DNS provider" OR "hosted on" postmortem
  • repo:prometheus-community/helm-charts is:pr is:closed is:unmerged watchdog
  • intitle:"who watches the watchers" monitoring
09

References

  1. Meta (Facebook), More details about the October 4 outage Published 2021-10-05. Checked 2026-10-18.
  2. AWS, Summary of the AWS Service Event in the N. Virginia (US-EAST-1) Region Published 2021-12-10. Checked 2026-10-18.
  3. AWS, Summary of the Amazon Kinesis Event in the Northern Virginia (US-EAST-1) Region Published 2020-11-25. Checked 2026-10-18.
  4. Roblox, Return to Service 10/28-10/31 2021 Published 2022-01 (event 2021-10-28 to 10-31). Checked 2026-10-18.
  5. Slack, Slack's Outage on January 4th 2021 Published 2021-01 (event 2021-01-04). Checked 2026-10-18.
  6. Cloudflare, Post mortem on Cloudflare Control Plane and Analytics Outage Published 2023-11 (event 2023-11-02 to 11-04). Checked 2026-10-18.
  7. Datadog, Multiregion infrastructure connectivity issue Published 2023-03 (event 2023-03-08 to 03-10). Checked 2026-10-18.
  8. Google Cloud, Google Cloud Networking Incident #19009 Published 2019-06 (event 2019-06-02). Checked 2026-10-18.
  9. GitLab, Postmortem of database outage of January 31 Published 2017-02 (event 2017-01-31). Checked 2026-10-18.
  10. Cloudflare, Cloudflare outage on November 18, 2025 Published 2025-11-18. Checked 2026-10-18.
  11. The Pragmatic Engineer (quoting Google), The Pulse: Firebase's global outage & poor response Published 2026-10-08. Checked 2026-10-18.
  12. Python Software Foundation, Infrastructure postmortem: DNS outage Published 2016-10-21. Checked 2026-10-18.
  13. prometheus-operator/kube-prometheus, kubePrometheus-prometheusRule.yaml: the Watchdog alert Published main branch (undated). Checked 2026-10-18.
  14. prometheus-community/helm-charts, PR #4753 [kube-prometheus-stack] Improve watchdog alert (closed, not merged) Published 2024-07-29. Checked 2026-10-18.
  15. prometheus-community/helm-charts, PR #4037 [kube-prometheus-stack] allow setting labels per Alert (closed, not merged) Published 2023-11-23. Checked 2026-10-18.
  16. prometheus/alertmanager, Issue #2407 Feature request: support GET for webhook receiver (closed as completed 2020-11-12) Published 2020-10-29. Checked 2026-10-18.
  17. prometheus-operator/prometheus-operator, Issue #3970 Support OpsGenie Heartbeat (closed 2021-09-06 via PR #4110) Published 2021-04-09. Checked 2026-10-18.
  18. alerta/alerta, Issue #1110 Improve Prometheus Heartbeat handling (DeadMansSwitch) (closed 2020-06-07) Published 2019-11-07. Checked 2026-10-18.
  19. Prometheus project, Alerting practices: Metamonitoring Published undated. Checked 2026-10-18.
  20. Grafana Labs (Loki docs), Meta monitoring (Loki operations) Published undated. Checked 2026-10-18.
  21. Grafana Labs (Mimir docs), Monitor system health (Mimir, next docs) Published undated. Checked 2026-10-18.
  22. Prometheus Operator community, Runbook: Watchdog Published undated. Checked 2026-10-18.
  23. Google, Site Reliability Engineering, chapter 6: Monitoring Distributed Systems Published 2016. Checked 2026-10-18.
  24. Mercari, Who Watches the Watchmen? Keeping an Eye on Our Monitoring Systems Published 2022-08-05. Checked 2026-10-18.
  25. OneUptime, Monitor Prometheus So Its Failure Cannot Silence Host-Down Alerts Published 2026-07-31. Checked 2026-10-18.
  26. Irin Observability (DEV Community), A Dead Man's Switch for Your Monitoring Stack Published undated (Jul 29). Checked 2026-10-18.
  27. haruodev (DEV Community), Our status page froze for four days because the CI minutes ran out Published undated (Sep 8). Checked 2026-10-18.
  28. InfoQ (Nanit), Nanit replaces monitoring-of-monitoring with a Dead Man's Switch (InfoQ news) Published 2022-05-19. Checked 2026-10-18.
  29. StatusPal, Learning from Facebook: Keep your Status Page Separately from your Infrastructure Published 2021-04-09. Checked 2026-10-18.
  30. Zabbix, Zabbix and SCADA: Who watches the watchers? Published 2020-07-01. Checked 2026-10-18.
  31. Google (Adams et al.), Monarch: Google's Planet-Scale In-Memory Time Series Database (PVLDB 13(12)) Published 2020-08. Checked 2026-10-18.
  32. Facebook (Pelkonen et al.), Gorilla: A Fast, Scalable, In-Memory Time Series Database (PVLDB 8(12)) Published 2015-09. Checked 2026-10-18.
  33. Google (Govindan et al.), Evolve or Die: High-Availability Design Principles Drawn from Google's Network Infrastructure (SIGCOMM 2016) Published 2016-08. Checked 2026-10-18.
  34. Microsoft (Parayil et al.), Detection Is Better Than Cure: A Cloud Incidents Perspective (ESEC/FSE 2023) Published 2023-12. Checked 2026-10-18.
  35. Stile Education (Nick Spain), Watching the Watchers: Generating Absent Alerts for Prometheus (SREcon21) Published 2021-10-13. Checked 2026-10-18.
  36. VictoriaMetrics (Mathias Palmersheim), How to Monitor your Monitoring (Conf42 Incident Management 2024) Published 2024-10-17. Checked 2026-10-18.
  37. Healthchecks.io, Pricing Published 2026-10-18 (fetched; page undated). Checked 2026-10-18.
  38. Better Stack, Pricing Published 2026-10-18 (fetched; page undated). Checked 2026-10-18.
  39. Atlassian, Statuspage pricing Published 2026-10-18 (fetched; page undated). Checked 2026-10-18.
  40. ITIC (via Calyptix), 2024 Hourly Cost of Downtime Survey, Part 2 Published 2024. Checked 2026-10-18.