In the early months of 2024, I was the platform engineer on-call for a logistics platform running more than 200 microservices. The platform processed real-time freight tracking, route optimization calls, and billing events. When it broke, the impact was immediate: shipments would go untracked, driver communications would fail, and customer-facing delivery estimates would freeze on stale data.
It broke a lot. Or rather, it degraded a lot, in ways that were serious enough to page someone at 3am but not catastrophic enough to have a clear, single cause. That was the problem.
The 3am gap
The pattern was consistent. Alert fires. Phone lights up. I open my laptop and start the familiar ritual: check the alert details, open Grafana, look at the metric that triggered, try to understand whether this is a real problem or a false alarm. If it's real, open a war room channel. Start pulling logs. Start checking recent deployments. The service graph for a 200-microservice platform doesn't fit in one screen, so I'm jumping between dashboards trying to build a mental model of what's affecting what.
Forty-five minutes in, I'd usually found it. A deploy from four hours earlier that introduced a subtle bug in how connection pools were initialized. A configuration change that increased the message batch size, causing the consumer lag to spike beyond the alert threshold when traffic volume hit a specific pattern. A downstream API whose response time degraded enough to cascade into our service's latency.
The fix was usually fast once I knew what I was fixing. Rollback the deploy, or change the config, or throttle the batch size, or wait for the downstream to recover. Five to ten minutes of actual work. The work before the work, the hour of diagnosis, was the problem.
I started asking a simple question: why didn't the alert tell me what was wrong? All the signals were there. The logs, the metrics, the deployment history, the service topology. Everything I used to diagnose the problem was in the system. I was just doing the work of correlating it manually, at 3am, under stress, from memory.
The tool I built to stop doing that manually
Late in the spring of 2024, I built an internal tool. Nothing sophisticated at first. It read deployment history from our CI/CD system, pulled the last 2 hours of metric anomalies from our Prometheus setup, and scanned log streams for error-rate spikes. When an alert fired via PagerDuty, it ran the correlation in about 30 seconds and dropped a message in Slack: "3 deploys in the last 90 minutes. The auth-service v2.4.1 deploy 47 minutes ago overlaps with the start of the elevated error rate. Likely candidate."
It wasn't always right. But it was right often enough that I started treating it as the first thing I looked at rather than the dashboards. And on the nights when it was right, the 45-minute diagnostic gap became a 5-minute confirmation gap. I already had a hypothesis. I just needed to verify it.
I ran this tool for about three months, refining it after every incident. I added a confidence scoring model. I added cross-service correlation, so it could see when a downstream service's anomaly preceded my service's anomaly. I added a natural-language query layer so I could ask "what changed in the billing service in the last 30 minutes" without having to manually pull the data.
By the end of summer 2024, I was using it for every incident. The other engineers on the team started asking to use it too. And a few people who'd left the company and gone to other engineering teams reached out and asked if they could use it at their new jobs. That's when I decided to build it as a product.
What the problem actually is
The standard framing of on-call pain is "too many alerts" or "alert fatigue." That framing isn't wrong, but it's incomplete. The alert is not the problem. The problem is the gap between the alert and the answer.
Modern observability stacks are genuinely good at detecting that something is wrong. Prometheus and Datadog and CloudWatch are excellent at measuring metrics and firing alerts when those metrics cross thresholds. What they don't do is tell you why the metric crossed the threshold. That's the gap. The alert says: "payment service error rate is 8%, above the 2% threshold." It doesn't say: "payment service error rate is 8% because the payment-worker v3.0.2 deploy 22 minutes ago introduced a change to the retry logic that causes transactions to fail under concurrent load patterns above 200 TPS, which is what your traffic looks like right now."
The second statement is what I wanted at 3am. Building the system that produces that statement is what Devtract does.
What we're building and what we're not
Devtract is an incident intelligence layer, not an observability platform. We don't replace Prometheus or Datadog or your existing logging stack. We read from them. The telemetry infrastructure most engineering teams already run generates everything we need to do the correlation work. We just do it automatically, in the 30-second window after an alert fires, before the on-call engineer has finished reading the page.
We're not trying to automate incident response. The decision of what to do during an incident belongs to the engineer. Devtract's job is to give them the best possible information at the start of that decision process, not to make the decision for them. There are important reasons for this distinction: the engineer knows their system's context, their team's risk tolerance, and their operational history in ways that no automated system fully captures. Giving them better information is additive. Removing their judgment is not.
We're also not an AIOps platform in the sense of "apply machine learning to everything and hope patterns emerge." The core of what we do is correlation: temporal correlation of events across telemetry streams, statistical correlation of change events with metric anomalies, and structured reasoning about which hypothesis has the most supporting evidence. This is not mysterious. It's the same reasoning process an experienced SRE uses, systematized and made fast.
Austin, bootstrapped, four people
We're a small team in Austin. Four of us right now, all with backgrounds in platform engineering or SRE. We're building this because we lived the problem, and we still live it. We're running Devtract on our own internal infrastructure, which means every bug and design mistake we ship lands on us first. We find it uncomfortable in ways that make us fix things quickly.
We're bootstrapped. That means we don't have a board to report to or a mandate to grow at any cost. It also means we're only growing if the product is actually useful to the people using it. That constraint focuses the work in ways that I think are healthy. We talk to every new customer ourselves. We read every piece of feedback. We respond to every support email from our engineering team, which is two people and a shared alias.
The thing I want to avoid is building a tool that sounds good in a demo but fails the actual test, which is: does the on-call engineer trust it enough to act on it? Trust is earned by being right more often than not and by being transparent when you're uncertain. It's lost quickly when a tool confidently points you at the wrong hypothesis and you spend 30 minutes chasing it.
The gap is worth closing
The cost of the diagnostic gap isn't just MTTR. It's the cognitive toll of being woken up regularly, being handed insufficient context, and being expected to reason clearly under stress. It's the engineers who burn out not from the volume of incidents but from the experience of being paged and not knowing what's wrong. It's the institutional knowledge that doesn't transfer because incident diagnosis is largely in the heads of the engineers who've seen the same failure modes before, not in the tooling.
If we get this right, the on-call engineer in two years shouldn't have to spend an hour correlating signals that are already in their systems. The work shouldn't be "figure out what's wrong." The work should be "verify the hypothesis, make the decision, fix the problem." That's a better job. It's a more sustainable job. And it's what the underlying technology, if you use it well, already makes possible.
That's why Devtract exists. We're a team that kept getting paged for problems we already had the data to diagnose. We got tired of doing the assembly by hand. Now we build the tool that does it for you.
If you're on-call and you recognize this gap, we'd like to talk to you. Not because we think we've solved it completely, but because we think it's worth solving together.