Research · Dependency management · Incident analysis
The Dependency Gap
Why an outage you caused and an outage your vendor caused look identical from inside your own monitoring - and what it takes to tell them apart.
A monitoring system that watches only your own services has a blind spot shaped exactly like your dependency graph. When a checkout flow starts failing, the alert says the checkout is failing. It does not say whether the cause is your code, your database, or the payment provider three hops away whose status page currently reads “all systems operational”.
Why the gap persists
Most teams resolve this by opening two tabs during an incident: their own dashboards, and the vendor’s status page. That comparison is weaker than it feels, for three reasons.
- A status page describes intent, not behaviour. It is updated by humans, after the fact, and it is scoped to the incidents the vendor has chosen to declare.
- Timing is approximate. An incident opened at 14:05 and closed at 14:40 does not tell you when your requests started failing, or when they recovered.
- The record is not yours. When you ask for a service credit, the vendor’s own page is the evidence - and it was written by the counterparty.
What closes it
The gap closes when your own failure record and an independent record of the vendor’s behaviour are kept on the same timeline. That is the product’s whole premise: monitor the external dependency directly, from outside the vendor’s control, and store the observations alongside your own incident history so the two can be compared at the minute level.
RELIASTRA checks each configured endpoint on a fixed interval and writes every observation - latency, status code, regional origin and outcome - to a retained history. When your own incident window overlaps a period in which the dependency was independently observed failing, that overlap is a fact about two measured timelines rather than an inference from a status page.
What this is not
It is not proof of causation, and the product does not claim that. A dependency failing at the same time as your service is strong evidence for where to look first; it is not a substitute for looking. Credit decisions belong to the vendor and to your contract. What changes is the quality of the record you bring to that conversation.
Evidence & data
- Every observation is written with its regional origin, so a single region’s network path cannot masquerade as a vendor-wide outage.
- Observations are retained per plan - from 24 hours on Free up to 90 days on Pro, with custom retention on Enterprise - and pruned by scheduled jobs rather than kept indefinitely.
- Generated evidence reports are checksummed and bound to the organisation that produced them. A public verification reference confirms a report exists and matches its checksum without disclosing endpoints, headers or account details.
Methodology & sources
This article describes the product’s design rather than a study, so there is no sampling method to disclose. The measurement method behind the observations it refers to is documented separately in How RELIASTRA measures vendor reliability.
Related research
- How RELIASTRA measures vendor reliability
Regional origination, retries, quorum and the refusals.
- The RELIASTRA research agenda
What we intend to publish, and what we will not.
- Track a vendor
Public, aggregated posture for vendors made public.
Independent research
Follow independent infrastructure research
If you find RELIASTRA’s independent infrastructure intelligence useful, add us as a Preferred Source - you’ll see future incident analysis and dependency research more often when you search.
Powered by Google - you choose your sources.