The Diagnostic Gap

Abstract

When a critical endpoint degrades, detecting the incident is often not the hard part. The hard part is what follows: an investigation across status pages, logs, and Slack channels trying to answer one question first. Is this our problem or someone else's?

This paper argues that a fundamental gap in modern incident management is not alerting speed or dashboard quality. It is dependency context: the ability to know, at the moment an alert fires, which upstream dependency is implicated and whether the problem is isolated to your stack or part of a wider event.

We call the space between the alert and that first answer the diagnostic gap. Every team has its own number for how long that gap lasts. Ask your engineers how long their last one took. This paper describes how dependency correlation, combined with deploy awareness, shortens that gap, and how the difference compounds across the incidents a team handles in a year.

The Problem Nobody Names Correctly

Ask any engineering leader what their biggest reliability challenge is and they will say something like "we need better monitoring" or "we need to reduce MTTR." What they are often describing is something more specific:

We spend more time figuring out what is wrong than fixing it.

This is the diagnostic gap. And it has a specific cause that most alerting workflows leave to the engineer.

Modern applications do not fail in isolation. When a customer-facing endpoint fails, two of the first possibilities an engineer must evaluate are an external dependency problem and a recent internal change. A payment processor goes down. An identity provider has an outage. A CDN region becomes unreachable. A fraud-scoring API starts returning errors. Or yesterday's deploy changed a configuration that nothing exercised until this morning's traffic.

When this happens, the monitoring tool fires an alert: your endpoint is degraded. Evaluating which of those stories you are in is left to the engineer.

The Anatomy of an Investigation

The following sequence is an illustrative composite, drawn from the kind of incident every operating team recognizes.

It is 2:14 PM on a Friday. An alert fires. The checkout flow is returning errors.

The on-call engineer steps out of a meeting, opens a laptop, and starts the familiar sequence:

• Check application logs → nothing obvious, errors are downstream
• Check cloud provider dashboard → compute and database healthy
• Check payment processor status page → "All systems operational"
• Check identity provider status page → "All systems operational"
• Check CDN status page → "All systems operational"
• Check the fraud-scoring vendor's status page → loading... still loading... "Investigating connectivity issues"

In this sequence, 32 minutes pass between the alert and the answer: the fraud-scoring provider is having issues. The checkout flow uses it to score transactions. Now the team can make a real decision: wait for the vendor to recover, or bypass fraud scoring with compensating limits in place and let checkout proceed. Either choice is defensible. Neither could be made until the cause was known, and the cause took more than half an hour to find.

Your team's diagnosis time may be shorter or longer. The shape of the sequence is the same, and it repeats around the clock. For a global business, 2:14 PM on a Friday in New York is 2:14 AM Saturday in Singapore. Peak traffic hours are always someone's middle of the night, and the investigation that follows costs the same regardless of the timezone.

The Real Cost of That Investigation

The investigation above was not one engineer's time. Consider who was involved:

• On-call Tier 1 engineer: pulled out of a meeting, investigating for half an hour
• On-call Tier 2 SRE: paged when Tier 1 could not immediately identify the cause
• Engineering manager: notified when the incident exceeded 15 minutes
• Possibly leadership: if customers started noticing

Run the arithmetic with your own numbers: people involved, times the length of a typical investigation, times how many investigations your team handles in a month. For a growing engineering team looking into 6 to 10 alerts per week, real incidents and false positives combined, that is roughly 25 to 45 investigations per month. Each one pulling in multiple people. Each one starting from zero context about what might have caused it.

The cost is not only financial. It is the gradual erosion of trust in the alerting system itself. Engineers who get paged repeatedly for issues that turn out to be vendor problems, problems they can only wait out or work around, eventually stop treating alerts with urgency. When that happens, the real incidents start getting missed.

Why This Problem Exists

Many monitoring systems evaluate each signal within the system that produced it. Endpoint monitoring reports endpoint health. Deployment systems record changes. Vendor status pages report vendor conditions. Even when these signals are all available, the engineer is often responsible for joining them during the incident.

Status pages illustrate the point, and they carry real signal. The problem is what an engineer has to do with them during an incident. First they need to know which status pages to check, and that is less obvious than it sounds. The engineer on call is rarely the engineer who wired in every service. Dependencies accumulate across a codebase over years, and the full list lives in nobody's head, least of all at 3 AM. Then, for each vendor they do think of, someone opens the page, finds the relevant component, and answers a harder question: does this reported issue actually affect our endpoint, in our region, on the services we use? Now repeat that across every vendor, while also checking whether a recent deployment lines up with the degradation. Each check is quick. The sequence is not. And the sequence happens at the worst possible time, when the team is paged and the clock is running.

Vendor updates also trail reality. Someone at the vendor has to notice the incident, assess it, and post an update, which can take tens of minutes. So the engineer is joining information that is incomplete, scattered, vendor-shaped rather than endpoint-shaped, and slightly behind the incident itself.

The gap is not any single source. The gap is that nobody holds the full picture, and nobody is doing the join.

Dependency Correlation: Closing the Gap

The insight behind dependency correlation is straightforward: if you know what an endpoint depends on before the incident happens, you can check those dependencies the moment the endpoint degrades.

At onboarding, you declare the dependencies associated with each endpoint:

checkout.yourapp.com depends on:
  - Payment processor API
  - Identity provider (US region)
  - Fraud-scoring API
  - Cloud CDN

Declaring dependencies once, in calm conditions, is what removes the 3 AM recall problem. The knowledge that normally lives across a team's heads is captured where the alerting system can use it, so the engineer on call inherits the full picture instead of reconstructing it.

Seismo probes each endpoint continuously, on a cadence of minutes. When checkout.yourapp.com degrades, it does not just fire an alert. In the same correlation pass it cross-references:

• Are the declared dependencies for this endpoint reporting problems?
• Did your team deploy inside the correlation window?
• Do the timings line up?

The alert that reaches the engineer does not just say "checkout is degraded." It separates observations from interpretation:

checkout.yourapp.com is degraded. Supporting evidence: Your fraud-scoring provider is reporting connectivity issues. Other declared dependencies currently appear healthy. No recent deployment was found in the correlation window. Most likely cause: The endpoint degradation is consistent with the reported vendor incident. Recommended next step: Confirm the affected vendor service. Monitor vendor recovery before changing your application.

A broad investigation can become a more focused confirmation. The engineer reads the alert, checks the assessment, posts an update to the team, and moves on with a concrete starting point.

The Deploy Correlation Layer

Not every incident is a vendor problem. Among the most common causes is a deployment: something that worked before the deploy and does not work after.

Seismo correlates endpoint degradation against recent deployment activity in the same pass as dependency checks:

Endpoint degraded 4 minutes after a deployment. All declared dependencies appear healthy. The deploy is the most likely cause. Recommended next step: review the changes in that deploy.

The "when did we last deploy?" conversation in the incident Slack channel, the one that happens in the first five minutes of every incident, is answered by a single line in the alert.

The correlation logic is specific:

Each scenario produces a different assessment and a different recommended action. The engineer receives not just a notification but a starting point.

Where Dependency Correlation Fits

Dependency correlation works alongside the tools an engineering team already runs. It is worth being precise about the role each one plays.

Alongside endpoint monitoring. Endpoint monitoring tells you your service is down, and many tools do it well. Dependency correlation picks up where that signal stops: it tells you where the problem most likely lives. Seismo includes endpoint probing as the trigger for everything else it does.

Alongside logs. Logs show what happened inside your application. Dependency correlation covers the territory outside it: the vendor APIs and infrastructure your application depends on. Together they cover the whole incident, inside and out.

Alongside observability platforms. Observability platforms give your engineers powerful tools to investigate incidents. Dependency correlation reduces the number of incidents that require that investigation. The two compound: fewer investigations, and better tools for the ones that remain.

Alongside status pages. Status pages carry real vendor signal, and Seismo puts them to work as corroboration. Your own check failing is the trigger. Vendor signals are layered in as explanation and supporting evidence, joined for you at the moment you need them.

Earlier Context, Better Communication

The sooner a team understands the likely source of a degradation, the sooner it can decide how to respond and what to communicate.

Dependency correlation gives the investigation a more informed starting point. Instead of beginning with an undirected search across dashboards and status pages, the engineer begins with the endpoint, its declared dependencies, recent deployment activity, and the evidence available at that moment.

That context can help the team communicate sooner, escalate to the right provider, or focus its investigation inside the application. The decision the team faced in the checkout example, wait for the vendor or activate a bypass, is exactly the kind of decision that earlier context unlocks.

Where This Goes

Everything described above is how Seismo works today: direct endpoint probing, declared-dependency status signals, and deploy correlation, synthesized into a single assessment. This section describes where the work goes next.

As adoption grows, Seismo may also use privacy-preserving, cross-client patterns to corroborate shared vendor incidents. When multiple engineering teams, each independently monitoring their own endpoints, simultaneously experience degradation on endpoints that share a common vendor dependency, that pattern is meaningful in a way no single team's data can be. One company's view of the internet is noise. Many companies' views corroborate each other. This capability is not part of the current production assessment and must be validated before it becomes a product claim.

The Compounding Value

The value of dependency correlation compounds.

Across incidents: Each incident that gets a useful assessment in minutes instead of a long undirected investigation is a discrete saving. Across dozens of investigations per month, the aggregate saving in engineering time and customer impact is substantial. Run the same arithmetic from earlier in this paper with the investigation shortened to a focused confirmation, and the difference is your number.

In trust: When engineers learn that alerts include useful context about the likely cause, they stop second-guessing alerts. Response times improve. The habit of alert-ignoring that develops in teams where false positives are common begins to reverse. The alert system becomes trusted infrastructure rather than background noise.

The Standard

Incidents will keep happening. Dependencies will fail, deployments will introduce regressions, and some causes will remain difficult to isolate.

The standard Seismo is built to meet is simpler: when an endpoint degrades, the engineer should have more than an empty page to start from. The alert should arrive with the relevant dependency signals, recent deployment context, supporting evidence, and a reasoned place to start.

Seismo's job is to make the diagnostic gap shorter and the investigation more focused.

That is a standard to be earned, one real incident at a time.

Try Seismo

Seismo is open to early customers. Try it free for 30 days at seismograph.ai and tell us what is useful, what is confusing, and what is missing.

About Seismo

Seismo is a managed monitoring platform that watches endpoints from the outside, the way users experience them, and watches the dependencies they rely on at the same time: cloud infrastructure, SaaS services, and recent deployments. When something breaks, the alert in your Slack shows the most likely cause, the supporting evidence, and the recommended next step.

seismograph.ai | [email protected]

© 2026 Seismo. All rights reserved.