Evidence ledger
37 sources
Checked 23 Sep 2026
Evidence ledger
One row per claim in The meter runs on cardinality: who published it, what grade it carries, when it was written, when the link was last checked, and the quote or figure it rests on. Nothing in the guide is cited from memory, so anything not in this table is not in the guide.
One row per claim. Every URL was fetched in this session (2026-09-23), either directly or by a research worker in the same session; the page's verifier re-checks each link. Where a paper is cited from a mirror, the canonical venue is named in the claim column.
Build-environment note: this guide was assembled inside a network policy that allowlists only a handful of hosts (github.com, raw.githubusercontent.com, gitlab.com, the datadoghq.com family, cloud.google.com, storage.googleapis.com, pricing.us-east-1.amazonaws.com). Sources on other hosts, including well-known accounts from Uber, Slack, Cloudflare, Pinterest, Shopify, Grafana Labs and Honeycomb's own blog, could not be fetched and are therefore not cited. That absence is an evidence limit of this build, not a statement about the public record.
| # | Org | Title | Tier | Published | Checked | URL | Claim I take from it | Supporting quote or figure |
|---|---|---|---|---|---|---|---|---|
| 1 | Datadog | 2023-03-08 Incident: Infrastructure connectivity issue affecting multiple regions | postmortem | 2023-05-16 | 2026-09-23 | https://www.datadoghq.com/blog/2023-03-08-multiregion-infrastructure-connectivity-issue/ | The largest published monitoring-vendor outage was triggered by an OS auto-update, and customers lost alerting itself | "a security update to systemd was automatically applied to a number of VMs, which caused a latent adverse interaction in the network stack"; "users could not access the platform or various Datadog services via the browser or APIs and monitors were unavailable and not alerting"; impact across "the US1, EU1, US3, US4, and US5 Datadog regions across all services" from 06:03 UTC 2023-03-08; "declared all services operational in all regions on March 9, 2023, 08:58 UTC" |
| 2 | Datadog | 2023-03-08 incident: A deep dive into the platform-level impact | postmortem | 2023-05-24 | 2026-09-23 | https://www.datadoghq.com/blog/engineering/2023-03-08-deep-dive-into-platform-level-impact/ | Cloud auto-remediation amplified the failure by destroying local state | "By 08:00, AWS had terminated and replaced approximately 60 percent of the instances"; "we lost all data stored on their local disks"; "Traffic went from hundreds of millions of packets sent per second to almost 0 between 06:00 and 07:00" |
| 3 | Datadog | 2023-03-08 incident: A deep dive into our incident response | postmortem | 2023-06-01 | 2026-09-23 | https://www.datadoghq.com/blog/engineering/2023-03-08-deep-dive-into-incident-response/ | The vendor watches itself from outside its own platform; response scale | "This is how we monitor the monitors"; detection "three minutes after the trigger of the first faulty upgrade"; "between 500 and 750 engineers working in shifts" over "nearly 48 hours"; support saw "about 25 times more tickets than usual over the first 12 hours" |
| 4 | Datadog | Failure is inevitable: Learning from a large outage, and building for reliability in depth | postmortem | 2025-10-15 | 2026-09-23 | https://www.datadoghq.com/blog/engineering/rethinking-reliability/ | The named false assumption: correctness-over-availability made the platform fail closed; the structural fixes and their measured effect | Bias toward "full stop over showing almost correct data"; "square-wave failure pattern: up, then instantly down"; fixes: retries "use strong backoff mechanisms to reduce overloading", "fall back to dead letter queues sooner"; results: 30% decline in significant incidents affecting customer monitors; metrics incidents now "affect only a limited number of metrics we process, usually less than 10%" |
| 5 | Datadog | Delayed Monitors Notifications (US1) | postmortem | 2026-09-21 | 2026-09-23 | https://status.datadoghq.com/incidents/g67lc6tmjnlt | Monitor-evaluation delay incidents remain routine after the 2023 rebuild; status entries carry no root cause | "delayed evaluations for metric, service check, composite, and SLO monitors in US1"; began 09:18 UTC 2026-09-21, roughly 1h12m to resolved; no root-cause statement published |
| 6 | GitLab | [Incident Review] 2020-04-22 Lack of Observability | postmortem | 2020-04-22 | 2026-09-23 | https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/9877 | The observability stack itself can be the outage: Thanos down took dashboards down while Prometheus kept collecting | "Prometheus and alertmanager were still operational, Thanos was completely unavailable"; roughly 600 minutes degraded; detected because "Grafana dashboards were timing out" |
| 7 | GitLab | 2022-01-27: Crashlooping Prometheus Pod | postmortem | 2022-01-27 | 2026-09-23 | https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6241 | Prometheus OOM crash loops from WAL corruption are treated as production incidents | OOM crash loop, "OOM errors and generating several alerts"; roughly 45 minutes (19:53 to 20:38 UTC); fix: corrupted WAL file removed; follow-up: "prometheus recovery on WAL file corruption" |
| 8 | GitLab | 2023-02-01: Some prometheus metrics are missing | postmortem | 2023-02-01 | 2026-09-23 | https://gitlab.com/gitlab-com/gl-infra/production/-/issues/8345 | Losing derived (recording-rule) metrics silently degrades troubleshooting even when raw metrics survive | "The problem was our thanos rule processes abruptly increased their memory demand and saturated their available memory capacity."; apdex and derived metrics missing 15:30 to 17:20 UTC, severity HIGH |
| 9 | GitLab | Incident Review: Mimir unavailable | postmortem | 2025-10-28 | 2026-09-23 | https://gitlab.com/gitlab-com/gl-infra/production/-/issues/20782 | A cardinality burst from routine pod churn OOMed enough ingesters to break quorum: full metrics write outage | "A failure in Mimir ingesters caused loss of quorum, resulting in full service outage and missing metrics."; "18 out of 210 ingesters were affected, which led to write failures and increased latency."; root cause "OOM kill on multiple ingesters due to high numbers of in-memory series."; 25 minutes, severity 2; fix: migrate to "the newer Mimir Ingest Storage architecture" to handle "cardinality explosions" |
| 10 | GitLab | 2026-05-25: Mimir issues, grafana looks very sad. | postmortem | 2026-05-25 | 2026-09-23 | https://gitlab.com/gitlab-com/gl-infra/production/-/issues/22205 | The meta-monitoring built to protect the metrics platform generated the query load that saturated it | Root cause: "Overly expensive meta-monitoring recording rules that created high-cardinality queries, saturating the system and resulting in backlogs and instability."; fix: "increased the max_queriers_per_tenant limit from 10 to 20 for meta-monitoring, which stabilized the system." |
| 11 | GitLab | Work on Mimir cost optimization | source | 2024-02-13 | 2026-09-23 | https://gitlab.com/gitlab-com/gl-infra/observability/team/-/issues/2841 | The dominant surprise cost of self-hosted metrics at GitLab was inter-zone network, not storage | "much higher than expected inter-zone AZ traffic costs"; levers considered: "running in a single AZ with failover options for a secondary AZ", "Spot instances could be a viable option" |
| 12 | GitLab | Mimir production readiness review | adr | 2023-11 onward | 2026-09-23 | https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/mimir/index.md | GitLab replaced Thanos because the observability stack had become its own incident source; the risk that survives the migration is named | "Over the past 18 months, we've had increasingly large numbers of incidents related to Thanos and Prometheus issues"; "The thanos-sidecar processes have had significant performance issues, timeouts, and crashes."; "Mimir is presently susceptible to the same 'poison query' issue that Thanos suffers from today" |
| 13 | token.place | 2026-09-02 production relay metrics-cardinality OOM postmortem | postmortem | 2026-09-03 | 2026-09-23 | https://raw.githubusercontent.com/futuroptimist/token.place/main/outages/2026-09-02-production-relay-metrics-cardinality-oom.md | Default framework instrumentation with request-controlled label values is a self-inflicted cardinality denial of service | "Default Flask request instrumentation retained request-controlled raw paths as labels"; histogram grew from 28,964 series (23:30 UTC) to 71,056 at peak (23:48 UTC); roughly 7.79 MB exposition responses every 30 s; 92.4% of the 256 MiB container limit; roughly 87 minutes of outage; re-enable criteria include verifying "unmatched paths map to a bounded label set" |
| 14 | Zendesk | Optimizing Datadog at scale: Cost-efficient observability at Zendesk | blog | 2025-12-26 | 2026-09-23 | https://www.datadoghq.com/blog/zendesk-cost-optimization/ | A marquee customer's steady state is mass exclusion: 1,435 filters, the most common excluding 99 to 100%, indexing a tenth of ingest | "Total exclusion filters: 1,435"; "Most common exclusion filter: exclude 99-100%"; "Ingestion-to-indexing ratio: 10:1"; "a fourfold reduction in volume for this high log volume service"; "We now maintain more than 100 custom facets" |
| 15 | Datadog | Introducing Husky | blog | 2022-05-17 | 2026-09-23 | https://www.datadoghq.com/blog/engineering/introducing-husky/ | The vendor decoupled storage from compute in its event store precisely so cheap retention tiers could be priced | "Even if a customer's data volumes are tiny, we can allow a query targeting one year of data to temporarily burst into a huge number of Reader nodes if we have spare capacity."; the engine queries "PiBs of events" |
| 16 | Datadog | Timeseries Indexing at Scale | blog | 2024-06-28 | 2026-09-23 | https://www.datadoghq.com/blog/engineering/timeseries-indexing-at-scale/ | Cardinality growth forced an index rewrite, and the rewrite was itself a cost win | Data volumes "increased 30x between 2017-2022"; "query 20 times higher cardinality metrics on identical hardware"; "99% reduction in query timeouts"; "50% cost reduction for the indexing service" |
| 17 | Netflix | Atlas docs: Overview | blog | living doc | 2026-09-23 | https://raw.githubusercontent.com/Netflix/atlas-docs/master/docs/overview.md | Netflix's prior system drowned at about 2M series in 2011; Atlas contains volume with age-tiered rollups | In May 2011 "the monitoring system was regularly failing to keep up with the volume of data" at roughly 2M distinct series; policy: under 4 days "early rollup by dropping the node dimension on some business metrics", under 16 days "Rollup by dropping the node dimension on all metrics", older: "Explicit whitelist"; "Keeping all data in memory is expensive" |
| 18 | eBay | Why and How eBay Pivoted to OpenTelemetry | blog | 2022-12-19 | 2026-09-23 | https://raw.githubusercontent.com/open-telemetry/opentelemetry.io/main/content/en/blog/2022/why-and-how-ebay-pivoted-to-opentelemetry/index.md | Sherlock.io scale, and agent topology alone as a 90% cost lever | "scrape around 1.5 million Prometheus endpoints"; "around 40 million samples per second"; "3 billion active series"; DaemonSet overhead "about 200MB (10x) and approximately 0.6 cores (60x)" per instance; "The overall savings by moving to a cluster local instance was roughly 90%." |
| 19 | Zerodha | Logging at Zerodha | blog | 2023-03-23 | 2026-09-23 | https://raw.githubusercontent.com/zerodha/zerodhatech.github.io/master/content/blog/logging-at-zerodha.md | ELK to ClickHouse: about 5x storage cut at equal volume, about 2.3x infra cost cut, tiered retention by level | "we now have around 30 billion log lines across our Clickhouse clusters, which collectively only take up 2.5TB of disk space"; "our previous ELK setup had 28 billion log lines, which required roughly 13TB"; "Clickhouse instance collectively costs only $1.14 per hour, whereas the ELK nodes cost us $2.67 per hour"; retention: debug 15 days, warn 30 days, others 90 days |
| 20 | Zerodha | Infra monitoring at Zerodha | blog | 2020-04-27 | 2026-09-23 | https://raw.githubusercontent.com/zerodha/zerodhatech.github.io/master/content/blog/infra-monitoring-at-zerodha.md | A small team runs VictoriaMetrics rather than Thanos at national-broker scale | "about 56 billion time series data points in our Victoria Metrics cluster"; "we handle around 15% of daily retail trading volume across all stock exchanges in India" |
| 21 | Wix, Roblox, Grammarly and others | VictoriaMetrics Case Studies | casestudy | living doc | 2026-09-23 | https://raw.githubusercontent.com/VictoriaMetrics/VictoriaMetrics/master/docs/victoriametrics/CaseStudies.md | First-person scale and cost figures from teams that migrated off Prometheus-family or SaaS stacks | Wix: "The number of active time series per VictoriaMetrics instance is 50 millions."; "The average churn rate is 150 millions new time series per day."; Roblox: "Active time series: 5 billion", "Data ingestion rate: 120 million data points per second"; Grammarly: "reduces costs and maintenance burden for their observability solution by 10x"; Dig Security: "We saved around $5K USD per month" |
| 22 | Nexthink | Datadog case study: Nexthink | casestudy | undated, fetched 2026 | 2026-09-23 | https://www.datadoghq.com/case-studies/nexthink/ | Containment tactics inside a SaaS contract: archive without indexing, watch custom metric count | "Nexthink can now archive logs directly to Amazon S3 without ingesting or indexing them."; 9.9k custom metrics; "For a similar budget, we are now processing significantly more data" |
| 23 | OpenTelemetry | OTEP 235: Sampling Threshold Propagation in TraceState | adr | 2023 | 2026-09-23 | https://github.com/open-telemetry/oteps/blob/main/text/trace/0235-sampling-threshold-in-trace-state.md | Multi-stage sampling only composes if decisions are consistent; the mechanism is a threshold carried in TraceState | "When sampling is to be performed at multiple points in the process, the only way to reason about it effectively is to make sure that the sampling decisions are consistent."; "spans where R >= T will be sampled"; "th is non-decreasing" |
| 24 | OpenTelemetry | tailsamplingprocessor README | source | current main | 2026-09-23 | https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md | Tail sampling bounds memory with a circular buffer that can silently drop a trace before its decision | num_traces default 50000, decision_wait default 30s; "A circular buffer is used to ensure the number of traces in-memory doesn't exceed num_traces. When a new trace arrives, the oldest trace is removed. This can cause a trace to be dropped before it's sampled."; "Both of those options increase memory usage." |
| 25 | OpenTelemetry | tailsampling: Offloading trace storage to disk for scalability (#42326) | source | 2025-08-28 | 2026-09-23 | https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/42326 | The community names memory-linear scaling as tail sampling's cost problem | "memory usage scaling linearly to throughput. Higher memory requirements translates to higher hardware cost"; disk offload could relax the knobs by "at least an order of magnitude" |
| 26 | OpenTelemetry | Add cardinality_limit for the batch partitions (PR #15225, closed unmerged) | source | opened 2026-04-29, closed 2026-09-17 | 2026-09-23 | https://github.com/open-telemetry/opentelemetry-collector/pull/15225 | A hard cardinality cap was rejected despite five approvals: eviction and rejection are competing containment philosophies | @dmitryax (2026-09-04): "I'm not sure I understand the purpose of adding this failure point...memory is bounded without rejecting anything. If we want to add this hard cap for some reason, we should remove LRU." |
| 27 | OpenTelemetry | Stabilize Overflow attribute under Cardinality Limits (#3904) | source | 2024-02-26 | 2026-09-23 | https://github.com/open-telemetry/opentelemetry-specification/issues/3904 | The SDK-level answer to cardinality explosion is eviction to a single overflow series, stabilized after four SDKs shipped it | Closed completed via spec PR #4222; the overflow attribute was "introduced in PR #2960 to handle cases where metric cardinality exceeds defined limits"; adoption across Go, C#, Java, Rust SDKs |
| 28 | Prometheus | Setting limits for maximum label value length (#8198) | source | 2020-11-19 | 2026-09-23 | https://github.com/prometheus/prometheus/issues/8198 | Real 400KB label values drove memory exhaustion; an earlier safeguard proposal had been declined | @hartfordfive: "I was quite disappointed when I noticed there was a issue created to propose adding a feature that would allow to safe-guard against this but was declined" |
| 29 | Prometheus | Add cardinality_limit to scrape config (#11061) | source | 2022-07-25, still open | 2026-09-23 | https://github.com/prometheus/prometheus/issues/11061 | Scrape-time cardinality capping has been proposed by a maintainer since 2022 and remains unresolved | @SuperQ: "add a scrape config limiter that limits the number of unique label values per scrape."; labels kind/feature, priority/P3, help wanted |
| 30 | Prometheus | Scrape configuration documentation | source | current main | 2026-09-23 | https://github.com/prometheus/prometheus/blob/main/docs/configuration/configuration.md | Prometheus's shipped containment is all-or-nothing: limits default off, and tripping one fails the whole scrape | sample_limit (default 0): "If more than this number of samples are present after metric relabeling the entire scrape will be treated as failed."; same semantics for label_limit, label_name_length_limit, label_value_length_limit; body_size_limit: "An uncompressed response body larger than this many bytes will cause the scrape to fail." |
| 31 | Prometheus | Proposal 0089: Query cost estimation and limits | adr | 2025-2026, not implemented | 2026-09-23 | https://github.com/prometheus/proposals/blob/main/proposals/0089-query-cost.md | Containment is moving to the read path: pre-execution cost estimates and hot-reloadable per-query ceilings | "A single expensive query can hurt a whole Prometheus."; startup-only limits "cannot be adjusted without restarting"; per-query parameters "may only lower server ceilings, never raise them" |
| 32 | VictoriaMetrics | Series cardinality limiter semantics (#9522) | source | 2025-07-31, open | 2026-09-23 | https://github.com/VictoriaMetrics/VictoriaMetrics/issues/9522 | The limiter itself has a performance cost, and its dual hourly/daily semantics confuse operators | "hitting the limit could lead to full vmstorage degradation since it goes via the slowest path"; "The index will be bloated anyway if we don't set a daily limit since index entries have per-day granularity." |
| 33 | Grafana | Loki: request validation and rate-limit errors | adr | current main | 2026-09-23 | https://github.com/grafana/loki/blob/main/docs/sources/operations/request-validation-rate-limits.md | Log-volume containment as layered per-tenant refusals, with the memory rationale written down | per_stream_rate_limit default 3MB, burst 15MB, recommended "no higher than 5MB" and "no higher than 20MB"; max_global_streams_per_user: "Active streams are held in memory buffers in the ingesters, and if this value becomes sufficiently large then it will cause the ingesters to run out of memory" |
| 34 | Grafana | Mimir README | vendor | current main | 2026-09-23 | https://github.com/grafana/mimir/blob/main/README.md | The vendor's claimed ceiling for an open-source metrics backend, and object storage as the cost lever | "Internal testing shows that Grafana Mimir handles up to 1 billion active time series."; object storage is the "cost-effective, high-durability technology" for long-term data |
| 35 | Honeycomb | Refinery README | vendor | current main | 2026-09-23 | https://github.com/honeycombio/refinery/blob/main/README.md | Mechanics of tail-based dynamic sampling for trace-volume containment | Dynamic sampling "automatically increases or decreases the sampling rate based on how frequently each unique value of that key occurs"; example: "one out of every 1,000 traces for requests that return 2xx" while keeping every 5xx; throughput sampling caps spans per second |
| 36 | Uber | M3 docs: Motivation | vendor | living doc | 2026-09-23 | https://raw.githubusercontent.com/m3db/m3/master/site/content/overview/motivation.md | Why Uber open-sourced its metrics platform | "We decided to open source the M3 platform as a scalable remote storage backend for Prometheus and Graphite so that others may attempt to reuse our work and avoid building yet another scalable metrics platform." |
| 37 | Dapper, a Large-Scale Distributed Systems Tracing Infrastructure (tech report, 2010) | paper | 2010-04 | 2026-09-23 | https://storage.googleapis.com/gweb-research2023-media/pubtools/pdf/36356.pdf | 1/1024 production sampling; full tracing costs 16.3% latency; even sampled traces were 1 TB/day in 2010 | "The first production version of Dapper used a uniform sampling probability for all processes at Google, averaging one sampled trace for every 1024 candidates."; Table 2: "1/1 16.3% -1.48% ... 1/1024 -0.20% -0.06%"; "Our production clusters presently generate more than 1 terabyte of sampled trace data per day."; collection sampling "often as low as 0.01% for high-traffic services" | |
| 38 | Gorilla: A Fast, Scalable, In-Memory Time Series Database (VLDB 2015; mirror of vldb.org/pvldb/vol8/p1816-teller.pdf) | paper | 2015-08 | 2026-09-23 | https://raw.githubusercontent.com/ghilesmeddour/gorilla-time-series-compression/main/doc/p1816-teller.pdf | Compression as the containment lever: 16 bytes/point to 1.37 bytes/point; a deliberately bounded 26-hour hot window | "more than 2 billion unique time series of counters, with about 12 million data points added per second"; "compress time series to an average of 1.37 bytes per point, a 12x reduction in size"; "Store data for 26 hours"; "we have had to double the size of the clusters twice due to data growth" | |
| 39 | Monarch: Google's Planet-Scale In-Memory Time Series Database (VLDB 2020; mirror of vldb.org/pvldb/vol13/p3181-adams.pdf) | paper | 2020-08 | 2026-09-23 | https://raw.githubusercontent.com/arpit20adlakha/Computer-Science-Papers-For-System-Design/main/Monarch-Time%20Series%20Database.pdf | The ceiling of the metrics arms race: about a petabyte in RAM, terabytes per second in | "It presently stores close to a petabyte of compressed time series data in memory, ingests terabytes of data per second, and serves millions of queries per second."; "runs in 38 zones spread across five continents" | |
| 40 | Canopy: An End-to-End Performance Tracing And Analysis System (SOSP 2017; mirror) | paper | 2017-10 | 2026-09-23 | https://raw.githubusercontent.com/tpn/pdfs/master/Canopy%20-%20An%20End-to-End%20Performance%20Tracing%20and%20Analysis%20System%20-%202017%20(sosp17-final14).pdf | Trace volume contained by per-tenant token buckets and edge sampling policies with owners and lifetimes | "Canopy currently records 1.3 billion traces per day."; a sampling policy names an owner, "a sampling strategy, either a probability or a rate", restraints, a lifetime and a verbosity level; a token "bucket rate-limits traces both globally and per-tenant." | |
| 41 | LightStep | Ben Sigelman, Three Pillars with Zero Answers, KubeCon NA 2018 keynote (slides) | talk | 2018-12-11 | 2026-09-23 | https://raw.githubusercontent.com/warmchang/KubeCon-North-America-2018/master/Three%20Pillars%20with%20Zero%20Answers%20-%20A%20New%20Observability%20Scorecard%20(Kubecon%20Seattle%202018).pdf | The log cost equation, the four-orders-of-magnitude retention funnel, and cardinality priced per tag value | Slide 11: "transaction rate x all microservices x cost of net+storage x weeks of retention = way too much $$$\("; slide 12: "Instrumentation Executed ... 100.00% / Buffered within app process ... 000.10% / ... Centralized globally WAN + storage 000.01%"; slide 24: "Cost of cardinality (\) per tag value)" |
| 42 | DigitalOcean | Tim Simmons, Adopting Prometheus the Hard Way, KubeCon NA 2018 (slides) | talk | 2018-12 | 2026-09-23 | https://raw.githubusercontent.com/sbueringer/kubecon-slides/master/slides/2018-kubecon-na/Adopting%20Prometheus%20the%20Hard%20Way%20-%20Tim%20Simmons%2C%20DigitalOcean%20-%20Adopting%20Prometheus%20the%20Hard%20Way.pdf | Fleet-scale Prometheus numbers and the operational cardinality bound | Slide 24: "192 Prometheus servers / 200M+ time series / 2M+ samples/second"; slide 26: "Every permutation of labels in Prometheus creates a new time series. Individual queries should use hundreds not thousands of time series (at most)."; slide 28: "You will need to shard the metrics across multiple Prometheus servers" |
| 43 | VictoriaMetrics | Diana Todea, Cutting Through Metrics Cardinality Noise, SREday London 2025 (slides) | talk | 2025-09-18 | 2026-09-23 | https://raw.githubusercontent.com/didiViking/Conferences_Talks/main/SREday%20London%202025-Cardinality%20talk.pdf | Practitioner root causes for cardinality cost and the over-collection factor | Slide 7: "Increased resource consumption (storage, memory, CPU) ... Increased cost"; slide 11: "You're over-collecting by 12x"; slide 10 root causes: "labels with a large number of unique values (user_id, request_id, url, ip)" |
| 44 | Datadog | Pricing list and custom metrics billing | vendor | fetched 2026-09-23 | 2026-09-23 | https://www.datadoghq.com/pricing/list/ | List prices: the billing atom for metrics is the series | Custom metrics "\(5" per 100 per month, ingested custom metrics "\)0.10" per 100 per month; logs "\(0.10 Per ingested or scanned GB, per month", indexed "\)1.70 Per million log events, per month" (15-day, annual), Flex storage "\(0.05 Per million events stored, per month"; APM "\)31 Per host, per month" |
| 45 | Datadog | Custom metrics billing definition | vendor | fetched 2026-09-23 | 2026-09-23 | https://docs.datadoghq.com/account_management/billing/custom_metrics/ | What counts as one custom metric | A custom metric is "a combination of a metric name and tag values (including the host tag)"; Pro includes 100 per host, Enterprise 200 per host |
| 46 | AWS | Price List API: AmazonCloudWatch, us-east-1 | vendor | 2026-09-22 | 2026-09-23 | https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonCloudWatch/current/us-east-1/index.json | CloudWatch's tiered metric-month and log-ingest prices | "\(0.30 per metric-month for the first 10,000 metrics"; "\)0.10 per metric-month for the next 240,000 metrics"; "\(0.05 per metric-month for the next 750,000 metrics"; "\)0.02 per metric-month for over 1,000,000 metrics"; "\(0.50 per GB custom log data ingested in Standard log class"; "\)0.03 per GB-mo of log storage" |
| 47 | Google Cloud | Google Cloud Observability pricing | vendor | fetched 2026-09-23 (logging price effective 2024-10-01) | 2026-09-23 | https://cloud.google.com/products/observability/pricing | GCP's unit prices for logs, metrics, managed Prometheus and trace | Logging "\(0.50/GiB" one-time ingest including 30 days storage, then "\)0.01 per GiB per month"; Monitoring "\(0.2580/MiB: first 150-100,000 MiB" tiering down to "\)0.0610/MiB"; Managed Service for Prometheus "\(0.06/million samples" tiering to "\)0.024/million samples"; Cloud Trace "$0.20/million spans" |
| 48 | OneUptime | The Real Cost of Observability in 2026 | vendor | 2026-03-17 | 2026-09-23 | https://raw.githubusercontent.com/OneUptime/blog/master/posts/2026-03-17-datadog-bill-shock-real-cost-observability-2026/README.md | A competitor's worked bill for a mid-market team; list-price claims, labelled as such | Worked scenario "~$18,400/mo" (about \(220,000 per year) for a 50-person team; logs "\)0.10/GB ingested plus $1.70/million log events" |
Deliberately not cited
- The widely reported "$65M per year" Datadog customer from the Q1 2023 earnings call (and its identification as Coinbase by The Pragmatic Engineer): every primary source for it sits on a host this build environment could not reach (investors.datadoghq.com, seekingalpha.com, blog.pragmaticengineer.com, news.ycombinator.com). Search-snippet text exists but was not verifiable here, so the figure appears nowhere in the guide.
- Uber's CLP log-compression figures (OSDI 2021): the paper is hosted only at usenix.org, which was unreachable, and the project README keeps its numbers inside images. Not cited.
- Grafana Adaptive Metrics customer figures, Honeycomb's sampling-economics posts, Slack and Cloudflare accounts: unreachable hosts, not cited.