The Role of Observability in Platform Reliability: From Alerts to Root Cause

Frequently Asked Questions

01.Do startups need observability before product-market fit?

Partly. A small team needs a few symptom-based alerts on signup, login and payment, which the DORA research program's monitoring guidance prefers over trying to alert on every possible cause. In my view, full tracing earns its cost once a request crosses several services and no single engineer can hold the whole path in their head.

02.What causes alert fatigue?

Alert fatigue comes from pages nobody can act on. The DORA research program's monitoring guidance says that if too many alerts are not actionable, teams easily miss the meaningful ones, and it suggests tracking the percentage of alerts judged unactionable (DORA, accessed October 2026). In my view, demoting those pages costs less than adding new tooling.

03.How does OpenTelemetry affect observability costs?

It changes what you pay for on some backends. On AWS CloudWatch, classic custom metrics are billed per metric and each unique dimension combination counts as a separate metric, while OpenTelemetry metrics are billed by the gigabyte ingested, with no per-metric charge (AWS CloudWatch pricing, accessed October 2026). CNCF says OpenTelemetry also lets organizations change analysis tools without rewriting code (CNCF, May 2026).

04.How fast must an incident be reported under DORA and NIS2?

Under the EU's DORA regulation, a financial entity sends its initial notification of a major ICT-related incident within four hours of classifying it as major and no later than 24 hours after becoming aware of it, or within four hours of a later classification (Delegated Regulation (EU) 2025/301, February 2025). Under NIS2 as transposed nationally, essential and important entities send an early warning on a significant incident within 24 hours of becoming aware of it and an incident notification within 72 hours (EUR-Lex, December 2022).