Teams struggle to deploy OpenTelemetry without complexity or bill shocks
Backend and platform teams adopting OpenTelemetry find instrumentation and collector setup tedious, especially across services and Kubernetes; some end up writing wrappers or custom scrapers to fill gaps. Once telemetry flows, small configuration changes can sharply increase usage-based bills, while reported performance overhead can make instrumentation hard to justify. Teams also want easier access to ingestion and dashboards without operating Grafana, pointing to an opportunity to make OpenTelemetry safer and simpler to adopt and run.
For backend and platform engineering teams adopting OpenTelemetry. Mentioned from May 2021 to Aug 2026 on Bluesky, product forums, GitHub and Hacker News.
9 different people described this problem in 11 separate discussions.
- Indie fit
- 6.0/10
- Pain
- 6.7/10
- Frequency
- 8.3/10
- Willingness to pay
- 0.0/10
- Momentum
- 4.7/10
- Who pays
- Businesses
- Competition
- High
- Build difficulty
- Medium
What people said
Quoted word for word. Follow a link to read the whole discussion.
CloudWatch metrics is such a footgun that I'm terrified when any engineer on our team submits a PR that includes them. It's so easy to accidentally 100-1000x your bill
bilalq on Hacker NewsJan 2024Setting up OTEL is definitely tedious, especially for traces and DT wasn't making it easier. I've been checking out a few alts, Signoz, Odigos, Chronosphere... there a few others too but these guys stood out.
See what to build and who will buy it
- 2 product ideas with the smallest useful version and pricing
- 5 places to find your first customers
- 9 more quotes from people who have this problem
- Current workarounds, existing solutions and risks