I've been building B2B SaaS for 10 years, and there's one loop I've never escaped:
Support gets a ticket: "What's happening with our data import?"
They ping engineering. Someone drops what they're doing, opens Grafana, filters, squints at some graphs, screenshots it, pastes it in Slack. Support forwards a cropped version to the customer.
Repeat 5x a day. 🤯
The tools exist, but not for everyone
Grafana and Datadog are incredible for devs. But I'd never hand them to support, let alone a customer.
Why?
-
PromQL: "Just use
rate(http_requests_total{customer_id="acme"}[5m])" is not something I can teach to someone in support - Infrastructure-centric: Everything is organized by pods, services, instances. Not customers.
- Trace IDs: Useful for debugging, meaningless to anyone outside engineering
- Dashboards assume expertise: Gauges vs counters vs histograms shouldn't matter if you just want to know "is this customer's workflow stuck?"
So we build internal admin panels. Or we stay in the loop forever.
What I'm trying instead
I started building DashFrog — open source, customer-scoped observability.
The idea:
- Organize everything by customer, not infrastructure
- Abstract away the OTEL complexity — spans become "Flows" you can follow step by step, metrics just work without needing to know what a histogram is
- Let anyone on your team explore what's happening with a customer
- Share views directly with customers when needed
It sits on OpenTelemetry, so if you're already using OTEL, you can pipe data in. But what shows up in DashFrog is designed for humans, not SREs.
Still early
I'm not pretending this is finished. I shipped it this week and I'm looking for feedback from anyone who's felt this pain.
If you're running B2B SaaS and tired of being the Grafana-to-Slack bridge, I'd love to hear:
- Does this problem resonate?
- What would you need to actually use something like this?
Top comments (0)