The Case Against the Five-Tool Observability Stack
The unbundling-then-rebundling cycle hit DevTools. Your on-call engineer shouldn't need five dashboards at 3am. Here's why observability tool consolidation is the next wave.
It's 3:14am. PagerDuty fires. Your on-call engineer — let's call her Priya — opens her laptop and starts the ritual: Datadog for metrics, Sentry for the stack trace, LogRocket to see what the user actually saw, Pingdom to check if the endpoint is down, and Google Analytics to see if traffic spiked. Five tabs. Five logins. Five different mental models. By the time she has context, twelve minutes have passed and your SLA is bleeding.
I've watched this scene play out at three different companies. The five-tool stack isn't a technical failure. It's an organizational one. And I think we're about to see the whole category rebundle. (We wrote about the cost of context-switching in incident response last month—the numbers were uglier than expected.)
The Unbundling-Then-Rebundling Cycle Comes for DevTools
If you've followed the enterprise software market for the past decade, you know the pattern. A monolithic incumbent gets fat and slow. Startups carve off vertical slices — each one doing one thing better than the generalist. The market unbundles. Everyone celebrates best-of-breed.
Then the complexity tax comes due.
Suddenly you're paying five vendors, managing five contracts, reconciling five data models, and — critically — asking your engineers to context-switch between five interfaces during incidents. The cognitive load compounds. The bills compound. And someone raises money to build the rebundled version that does 80% of everything under one roof.
We saw this with Salesforce eating point solutions. We saw it with HubSpot consolidating marketing tools. We're seeing it now with Notion absorbing the productivity stack. And we're about to see it with observability. (The same consolidation logic applies to fraud detection in ad spend—why run five tools when one covers the full funnel?)
Here's the thing: Datadog itself was a rebundling play. Remember when you had separate tools for infrastructure monitoring, APM, and logs? Datadog rolled them up. The market rewarded them with a $40B valuation. But Datadog stopped short of the full picture. They don't do session replay. They don't do uptime checks. They don't do web analytics. And their pricing model — which scales with hosts and custom metrics — creates perverse incentives that punish you for instrumenting deeply.
The next rebundling wave goes further. One script. One bill. One context.
Why Best-of-Breed Observability Made Sense (Until It Didn't)
I'm not here to trash Sentry or LogRocket or Pingdom. They're good tools. I've used all of them, and in specific contexts, each one genuinely is the best-in-class option.
Sentry's error grouping is really good. They've spent years tuning their stack trace deduplication, and it shows. 50,000 errors that are actually 12 distinct issues? Sentry figures that out faster than anyone.
LogRocket's session replay is pixel-perfect. The DOM diffing algorithm they built is a real technical achievement—I'm genuinely impressed by the engineering. For debugging frontend issues where you need to see exactly what the user saw, nothing else comes close.
Pingdom (and its descendants like Better Stack) nail the simple job of "is it up?" with minimal configuration.
The problem isn't that these tools are bad. The problem is that they don't talk to each other in the moment that matters.
When Priya gets that 3am page, she doesn't need the best error tracker OR the best replay tool OR the best uptime monitor. She needs the connection between them. She needs to know: this error happened to this user who was on this page who came from this traffic source and the root cause is this span in this service. One story. Not five fragments.
(I've been Priya. More times than I want to admit. The worst part isn't the context-switching—it's that sinking feeling when you realize you've been debugging the wrong service for ten minutes because you misread a timestamp in a different timezone format. For teams doing browser-based testing, JustBrowser solves a related problem—context fragmentation across test environments.)
And right now, building that story requires manual correlation. Session IDs don't match. Timestamps? Close-enough but not identical. User identifiers are different shapes in every tool—email here, anonymous ID there, some custom user_id field in a third. You're doing data integration in your head at 3am while customers tweet at your CEO.
Maddening. I've literally yelled at my laptop during incidents. Not proud of it.
That's the real cost of the five-tool stack. Not the $2,400/month in SaaS bills (though that's real). The cost is the 8-12 minutes of context-building before your engineer can even start fixing the problem.
The OpenTelemetry Shift Changes Everything
Here's where I lose most people: I think the "best-of-breed" argument for observability is about to collapse. Not because the tools got worse, but because the data layer got standardized.
This is the spicy take that got me uninvited from a Slack channel once. Worth it.
OpenTelemetry won the standards war. Full stop. It's CNCF-graduated, every major cloud vendor supports it, and the instrumentation libraries are production-ready. That matters because it means raw telemetry collection is now commoditized. (If you're curious how to instrument your app with OTel, we have a practical OpenTelemetry setup guide that skips the CNCF jargon.)
When Sentry launched, part of their value was the SDK. You installed their package, it hooked into your runtime, it captured errors with the right context. That was real engineering. But now? The OpenTelemetry SDK does that. And it sends data in a format that any backend can ingest.
The differentiation is moving up the stack. Not "can you capture the data?" Everyone can capture the data now. But "can you make sense of it?" And making sense of it requires... context.
A consolidated platform has context that siloed tools can't match. When errors, traces, replays, analytics, and uptime data live in the same database with the same session ID, correlations that used to require manual investigation become automatic. "This error spiked when that deploy went out" isn't a hypothesis you have to test — it's just visible.
The contrarian take: in 18 months, teams running five best-of-breed observability tools will look like teams running five separate CRM tools looked in 2015. Theoretically defensible. Practically exhausting.
What This Means If You're Running Platform Engineering
So what do you actually do about this?
First, audit your current stack honestly. Write down every tool your on-call engineers touch during incidents. Time how long it takes to establish context. I've run this exercise three times at different companies, and the answer is always worse than leadership thinks. The median was 11 minutes of context-switching before the first meaningful debugging action. (We published a stack audit template if you want a starting point.)
Second, calculate the real cost. Not just the invoices — the engineer-hours. If you're paying a senior SRE $180K/year and they spend 20% of their time on context-switching between tools, that's $36K/year in hidden tool-sprawl tax. Multiply by team size.
Third, look at what's actually vendor-specific vs. what's OpenTelemetry-portable. If you've instrumented with the OTel SDK, you can swap backends without re-instrumenting. That's the exit strategy. If you're locked into vendor-specific SDKs, extraction gets harder with every passing quarter. (Teams managing multiple dev environments can use DevOS to standardize tooling configs across the org.)
Fourth — and this is the hard one — consider whether you're optimizing for the wrong thing. Best-of-breed tooling optimizes for depth in each silo. But incidents don't happen in silos. Your users don't experience errors in isolation from the page they were on, the trace that served them, and the uptime status of your dependencies. The tool that wins the next decade will optimize for connection, not depth.
I could be wrong. Maybe I'm just bitter from too many 3am pages. But I don't think so.
Honestly? I spent two years defending the five-tool approach at my last job. Built elaborate Terraform modules to deploy all five. Wrote runbooks for the hand-off between them. We even had a Slack bot that would auto-link related alerts. It worked. Sort of. Until someone asked why we had three engineers maintaining observability glue code instead of shipping features. That one stung.
I'm biased — we built JustAnalytics to be that tool. One under-5KB script that covers analytics, errors, APM, session replay, uptime, and structured logs. When an error fires, you see the user's session: the pages they hit, the actions they took, the trace that served them, the replay of what they saw. No tab-switching. And because it's one bill, there's no "we can't afford to add session replay" tradeoff — it's just included at $49/month.
But even if you don't pick us, pick something. The five-tool status quo is a tax on every incident, and your engineers are paying it at 3am.
My Prediction for 2027
By Q4 2027, at least two of the current best-of-breed observability vendors will have either acquired each other or been acquired by a consolidation play. The standalone error-tracking or standalone session-replay market will contract. Not because those tools got worse, but because the market will decide that integrated context beats siloed depth.
The winners will be the platforms that nail the OpenTelemetry-native backend (so you can migrate easily), offer a single-script frontend deployment (so you don't need five separate instrumentation layers), and price predictably instead of scaling with infrastructure size (so you don't get punished for instrumenting deeply).
Datadog might pull it off if they add replay and web analytics. But their pricing model is a structural problem — they make more money when your infrastructure sprawls, which creates misaligned incentives. (Speaking of misaligned incentives, if you're sending outbound sales calls, VeloCalls applies similar consolidation thinking to sales engagement.)
The smaller players — us included — have a window. We're small enough to be opinionated about consolidation, and we don't have a legacy pricing model to protect. Also small enough to ship fast and break things. That cuts both ways.
If I'm wrong about this, I'll write the follow-up post in Q1 2028 explaining why best-of-breed held on. But I don't think I'm wrong. The rebundling cycle is coming for observability the same way it came for CRM, marketing automation, and productivity tools.
Your on-call engineer at 3am will thank you for getting ahead of it.
(Or curse you for making them learn a new tool. Can't win 'em all.)
Frequently Asked Questions
Why did observability tools unbundle in the first place?
Best-of-breed unbundling happened because each category — error tracking, APM, logs, uptime — had genuine technical depth that generalist tools couldn't match. Sentry built better stack traces than any APM vendor. Datadog built better metrics than any logging tool. But now the standards layer (OpenTelemetry) means raw data collection is commoditized, and the differentiation is moving to UX and insights.
Doesn't consolidation mean worse tooling in each category?
That was true in 2020. It's less true in 2026. OpenTelemetry standardized the instrumentation layer, which means a consolidated platform can ingest the same telemetry data as best-of-breed tools. The question is now about the insight layer — grouping, alerting, visualization — where a single-context tool has advantages a siloed one can't match.
What's the real cost of a five-tool stack beyond the bill?
The hidden cost is cognitive load at incident time. Five logins. Five mental models. Five places to check before you understand a single user's bad experience. We've watched senior SREs take 8-12 minutes just to establish context during an incident — time that directly extends your MTTR and your customer's pain.
How does JustAnalytics approach consolidation differently?
One script, under 5KB. Analytics + errors + APM + session replay + uptime + structured logs in a single platform with shared session context. When an error fires, you see the analytics events that preceded it, the replay of what the user saw, and the distributed trace that shows which service failed. No tab-switching. Free tier at 100K events/month, Pro at $49/mo.
Try JustAnalytics
All-in-one observability in one under-5KB script: cookieless analytics + error tracking + APM + session replay + uptime + structured logs. Replaces GA4 + Sentry + Datadog + Pingdom + LogRocket. Free tier (100K events/mo), Pro $49/month ($39 annual).
Author at JustAnalytics.