External dependency intelligence
Infrastructure you can prove.
Your infrastructure does not stop at your network edge. RELIASTRA independently observes the third-party services you depend on, aligns their failures with your incidents, and produces evidence you can hand over.
One observation point today, and every surface says so, including the ones where it weakens the claim. Read the methodology.
- up200 · 181 ms
- up200 · 184 ms
- failedconnect timeout- · -
- failedconnect timeout- · -
- failedservice unavailable503 · 2 ms
Incident opened
2 consecutive failures
single.consecutive_failures · started 09:53:00Z · us-east
Evidence record
- report
- ev_8Kd2xQ7m
- data hash
- 3f9a…c41e
- methodology
- v1.0
- retention
- 365 days
- Observation point
- us-east
- Probe interval
- every 300s
- Confirmation rule
- single.consecutive_failures · 2
- Evidence
- SHA-256 · retained 365 days
Telemetry values marked illustrative are illustrative. The fields are the real schema.
ScrollYour infrastructure includes services you do not operate.
When a third-party dependency degrades, your users file it under your name. RELIASTRA gives you the observation record that shows where it actually failed, and evidence that still verifies after the incident is over. Start with one endpoint.
01The problem
Your monitoring stops at your edge.
Your infrastructure includes services you do not operate. Your APM sees your own errors, not their cause. The vendor status page is written by the vendor.
Between those two facts is the only record that settles the argument: what the dependency actually did, measured continuously by someone with no stake in either answer.
A request path, with its blind spots
user
application
your infrastructure
your network edge · your monitoring ends here
edge / network
payments
identity
model apis
messaging · data
vendor internals · no outside observer sees here
Service classes are illustrative. Any HTTP endpoint can be observed, and naming a service implies no relationship with it.
02Observe
Independent checks, outside your network and the vendor's.
Probes run every 300 seconds from infrastructure that is neither yours nor the vendor's, and every probe leaves a row: timestamp, status, latency, verdict. us-east is the single observation point today, printed on the records it produces.
- RELIASTRA observation point
- failed check
- 2 consecutive failures, 300s apart, confirm the incident
03Correlate
Dependency behaviour, aligned with your incident window.
Failing checks are replayed against the strict clock of the observations: 2 consecutive failures open the incident, 2 consecutive successes resolve it, and the rule identifier travels with the record. One dropped probe is recorded, not declared.
Illustrative incident · not a recorded event
- 09:12:41Your application
Your application reports elevated failures
Checkout error rate rises. Your own monitoring cannot tell you whose fault it is.
- error_rate
- 4.8%
- source
- your telemetry
- 09:13:02RELIASTRA
RELIASTRA observes external degradation
A scheduled check against the same dependency, issued every 300s from infrastructure the vendor does not control. One failure is recorded, not declared.
- region
- us-east
- status_code
- 503
- latency_ms
- 4120
- is_up
- false
- 09:13:44RELIASTRA
A second consecutive failure confirms the incident
Confirmation is by persistence of failure: 2 consecutive failed checks are required, and this is the second. No agreement between independent points is claimed.
- executed_at
- 09:13:44
- status_code
- 503
- latency_ms
- 3870
- detector_confirmed
- true
- 09:15:10Attribution engine
Incident attributed to the external dependency
Five weighted signals produce a reproducible confidence score. No model is involved.
- classification
- vendor_failure
- confidence
- 91.25
- methodology
- v1.0
- 09:16:03Evidence record
Evidence record finalized
The window, the detection rule, the retained observations and a SHA-256 checksum of the report.
- duration
- 35m 25s
- observations
- 142
- sha256
- 9f2c…5a17
04Attribute
From incident to named contributor.
The investigation is arithmetic, printed with its weights: five signals, two thresholds, one versioned verdict.
- Application incident
Checkout API
elevated 5xx · 09:53:00 - 10:09:00 UTC
- Dependency signal
payments-api
connect timeout · 2 consecutive checks
- Correlated window
00:16:00
observation range, one interval apart
- Likely contributor
vendor_failure
rule 75+ · methodology v1.0
- Evidence
ev_8Kd2xQ7m
19 observations · sha-256
One illustrative incident · shown to demonstrate the investigation, not a live reading
vendor_failure
- Endpoint overlap+25.00weight 0.25
Affected endpoints shared with the suspected dependency
- Latency correlation+21.25weight 0.25
Latency movement against your error rate
- Temporal overlap+18.00weight 0.20
Other incidents open in the same 300s window
- Error pattern+12.00weight 0.15
Status codes returned by the dependency
- Infrastructure baseline+15.00weight 0.15
Whether your own infrastructure was healthy
Deterministic. Signals are weighted, summed and rounded; the same inputs always produce the same score. A score of 50 or more is multi_cause; 75 or more is vendor_failure. At 91.25 this clears the higher bar. No model is involved in this decision.
Classification, in the open
A score is an alignment between two timelines. It is not proof of causation, and no surface in this product describes it as one.
05Prove
Timestamped evidence that survives the incident.
A resolved incident becomes an artifact: the window, every observation inside it, the arithmetic behind the availability figures, the attribution verdict with its version, and a SHA-256 checksum over the payload. Written once, retained 365 days, verifiable by a third party with no account.
Independently measured · signed record
payments-api
Major dependency event on payments-api - resolved: 83.33% measured availability over 35 min 25 s
Incident window
35 min 25 s
14 Nov 2025, 09:12 → 09:48 UTC
Measured availability
83.33%
30 of 36 measured checks reached the target
Measured downtime
5 min 54 s
inside a 35 min 25 s window, 6 failed check(s)
Attribution
Vendor failure
91.25% confidence · v1.0
What the record shows
- 6 of 36 checks issued to https://api.payments.example/v1/charges failed inside a 35 min 25 s window beginning 14 Nov 2025, 09:12:41 UTC. Measured availability for the window is 83.3333%, computed from these checks only.
- The longest unbroken run of failed checks was 6, at 1 observation point. The detection rule that opened this incident was recorded as “Consecutive failed checks (single observation point)”.
- The attribution engine classified this as “Vendor failure” at 91.25% confidence under methodology v1.0. That classification describes what the timelines support, not fault or liability.
- Every observation here was issued from a single RELIASTRA observation point. Confirmation is by persistence of failure over 35 min 25 s, not by agreement between independent points, and no cross-verification is claimed.
1. Incident RecordFinal · incident resolved
3. Incident Window Measurements
4. SLA Impact Calculation
8. Deterministic Attribution
https://reliastra.com/reports/rsl_ver_7Q4M2X8A3RK9TZ0B
Retained for 365 days, then deleted: only the hashes recorded at the verification address remain checkable. Sections 1, 3, 4 and 8 are shown; the full document carries eleven, including the observation appendix and this block in full. Headings, labels and formatting are the ones the generated report uses; the values are an example, not a recorded incident.
06Public dependency index
The same probes, published.
What RELIASTRA's own probes observe. Not vendor-reported, no account required, every figure printed with its window and its observation count.
- Auth0authLast checkLatency439 msOperational
- CloudflarecdnLast checkLatency101 msOperational
- OpenAIaiLast checkLatency690 msOperational
- StripepaymentsLast checkLatency357 msOperational
- TwiliocommunicationsLast checkLatency37 msOperational
Per vendor: current state, availability with its observation count, latency, incident history and the methodology that produced each figure.
07Research
The method is published.
08Agencies
Dependencies across every client.
Every client estate watched from the same account and the same observation point, with evidence you can hand to the client when a vendor costs them money.
payments
observed endpoint
identity
observed endpoint
cdn
observed endpoint
database
observed endpoint
messaging
observed endpoint
model api
observed endpoint
identity
observed endpoint
storage
observed endpoint
dns
observed endpoint
Illustrative estate · any HTTP endpoint can be observed
09Pricing
One plan. $9 a month.
Every capability the product has, on every account. No plan ladder, no seats, no annual negotiation, and no tier where the evidence gets better.
The plan
14-day trial on every new account. No payment method required to start, and nothing that expires into a locked account.
- Dependencies
- 25 monitored
- Check interval
- 30-second checks
- Retention
- 3 months
RELIASTRA's plans are priced in USD. Our current Paystack payment flow processes payments in NGN. We are awaiting confirmation of additional payment options for international customers.
- What is RELIASTRA?
- An external dependency observation product. It probes the third-party services your software depends on, from infrastructure you do not operate, records what each probe saw, and keeps a verifiable record of what happened.
- What does it observe?
- Any HTTP endpoint that returns a status code: payment providers, identity providers, cloud platforms, model APIs, messaging, managed databases, DNS.
- How is an incident confirmed?
- Deterministically, by persistence: 2 consecutive failed checks from the reliastra observation point open an incident, and 2 consecutive successes resolve it. One dropped probe is recorded, not declared.
- How many places does it probe from?
- One today. There is no regional quorum claim, because a quorum needs genuinely independent observation points and this deployment has one. When that changes, the site and the records will say so.
- What is in an evidence record?
- The dependency, the incident window and the observation topology behind it, every observation in the window, the arithmetic behind the availability figures, the attribution result with its methodology version, and a SHA-256 checksum over the payload.
- How does attribution work?
- Deterministically, from five weighted signals summing to 1: temporal overlap, endpoint overlap, latency correlation, error pattern, infrastructure baseline. A score at or above 75 classifies as vendor failure; below 50 the result is often `unknown`, which is a result rather than an error.
- Who can see my monitoring data?
- Only your account. Dependency endpoints, headers and evidence records are never shared with the vendors being measured, and customer dependencies never appear in the public observatory.
RELIASTRA is built and maintained by Adeshina Emmanuel, an infrastructure security engineer working on identity, access control and system hardening across cloud, Kubernetes and AI environments. The detector, the evidence format, the research and the product are one person's work, which is why it is one price, and why the person who built it answers the support inbox.
Where the network is going
- 01Independent observations - what RELIASTRA measures itself, today.
- 02Application signals - what a participating application can report about its own dependency calls.
- 03Correlation - the same dependency degrading for unrelated applications at the same time.
- 04Attribution - a dependency’s behaviour described from many vantage points instead of one.
The first step is the product. The rest is described as direction, not as capability: nothing above is measured, counted, or rendered as a live figure anywhere on this site.
Begin
Add one dependency you already own.
Read what the probe records for a day before deciding whether the rest of it is worth your attention. The trial needs no card.