Episode Summary
Executive Summary: Charity Majors argues that observability is about understanding software in business terms, not just tracking outages. She critiques the legacy “three pillars” model, explains why high-cardinality structured data, unified storage, and OpenTelemetry are reshaping the field, and emphasizes that observability should accelerate development, support SLO-based operations, and remain central as AI-generated software increases complexity.
Main Topics: From monitoring to true observability: Majors defines observability as understanding the intersection of code, systems, users, and business outcomes, expanding the concept beyond alerts, crashes, and uptime. Why the three-pillar model is outdated: She critiques metrics/logs/traces as a vendor-driven abstraction that fragments data across tools, creates expensive duplication, and forces engineers to manually correlate signals. High cardinality, structured data, and unified storage: A major theme is that modern observability requires wide structured events and storage that can preserve high-cardinality context, enabling flexible slicing, correlation, and faster debugging. Observability 2.0 and development workflows: Majors frames observability as part of the full development loop—CI/CD, feature flags, canaries, and production validation—rather than a post-incident ops tool. OpenTelemetry and reduced vendor lock-in: OpenTelemetry is presented as a key enabler of portability, standardization, and vendor competition, helping teams avoid ecosystem lock-in while keeping instrumentation consistent. SLOs, platform teams, and organizational ownership: She argues that SLOs should be the operational contract and entry point for debugging, and that platform teams are better suited than siloed DevOps/SRE ownership for observability tooling. Observability in the age of AI: Majors sees AI observability as inseparable from general software observability: the problem is trace-shaped, high-dimensional, and requires context across humans, services, and model outputs.
Key Arguments: The three-pillars model encourages duplicated storage and manual correlation across logs, metrics, traces, profiling, and analytics tools, making debugging expensive and slow. Observability should help engineers explain software in the language of the business, not just diagnose incidents; it should connect engineering work to value and goals. Metrics are useful but fundamentally limited for high-cardinality, context-rich debugging; structured events and unified storage provide much more power. Modern observability is less about postmortems and more about faster feedback loops during development, CI/CD, and safe production rollout. OpenTelemetry is a major unlock because it standardizes instrumentation and makes telemetry portable across vendors, reducing lock-in. SLOs work best when they are derived from the same data used for debugging, turning them into actionable budgets rather than disconnected reporting artifacts. AI systems increase the need for observability because they introduce non-determinism, unknown code origins, and multi-step traces spanning software, users, and human feedback.
Data Points: Parse mobile apps at acquisition: ~60,000 - Parse had roughly sixty thousand mobile apps when it was acquired. Parse mobile apps by departure: over 1,000,000 - By the time Majors left Parse, the platform had exceeded one million mobile apps. Honeycomb age: 9 years - Majors says Honeycomb had been building for nine years as of January 1. Typical observability spend: 15% to 20% of cloud spend - She gives this as a reasonable rule of thumb for observability costs. DataDog bill example: $200,000/month to $2,000,000/month - She cites a case where cardinality changes caused a massive bill jump over a weekend. OpenTelemetry project rank: #1 CNCF project - She says OpenTelemetry overtook Kubernetes as the top CNCF project by commits and committers. OpenTelemetry portability: 90% to 95% true - She estimates the claim that OTEL lets you point telemetry to any vendor is about 90–95% true. Vendor consolidation: 5 vendors x 15% each - She notes that paying multiple observability vendors can stack up far beyond sustainable cloud-spend ratios. Production rollout window: 15–20 minutes - She references shipping code quickly and using observability immediately while changes are still fresh in memory. Kafka recovery practice: Every Monday - She says Honeycomb kills the oldest Kafka node every Monday to test bootstrap/recovery. Mobile/real user monitoring: RUM - She notes Honeycomb launched a front-end replacement focused on real user monitoring.
Pivotal Quotes: "Observability has three pillars: metrics, logs, and traces." — Charity Majors: Explaining the legacy model that she believes has distorted the market and tooling. "The goal… is to help engineers explain and understand their software in the language of the business." — Charity Majors: Describing Honeycomb’s mission and her broader definition of observability’s purpose. "If you can compute the answer, you should probably compute the answer." — Charity Majors: Her critique of AI-washing in observability products when the system already has enough context to derive a deterministic result.
Implications: Teams should instrument early, prefer structured high-cardinality data and OTEL, tie observability to SLOs and development workflows, and treat AI systems as traceable software problems. The industry is moving toward unified, portable, lower-friction observability.