Platform
Observe. Correlate. Prove.
RELIASTRA does four things, and each of them is a place where a weaker tool starts guessing. This page states what each step does, what it is allowed to conclude, and what it deliberately does not.
The pipeline
Four steps. No guessing.
- 01
Probe
An HTTP request every 300 seconds by default, from one observation point, reading status and headers and closing the connection.
Observation point: us-east
- 02
Confirm
2 consecutive failed checks open an incident; 2 consecutive successes close it. A pure function of the stored rows.
Rule: single.consecutive_failures
- 03
Attribute
Five weighted signals, summed and compared against two thresholds. Deterministic, versioned, and printed next to every verdict.
Methodology v1.1
- 04
Record
A resolved incident becomes an artifact: the window, every observation in it, the arithmetic, the verdict, and a checksum over the payload.
Retained 365 days, verifiable without an account
Observation
What a probe records, and nothing more.
Six fields, one row per probe. Everything downstream - the confirmation, the availability arithmetic, the artifact - is derived from rows like this one, which is why they are retained individually rather than aggregated on write.
- executed_at
- UTC timestamp the probe completed
- status_code
- HTTP status, or null on a transport error
- latency_ms
- Wall-clock time from request to completed response, redirect hops included
- is_up
- The pass/fail the detector reads
- error_message
- Transport error text, when there was one
- region
- Scheduling label of the worker that ran the probe
[
{
"id": "c_01J8K4",
"dependency_id": "dep_9f1c",
"executed_at": "2026-09-18T09:53:00Z",
"status_code": null,
"latency_ms": null,
"is_up": false,
"error_message": "connect timeout",
"region": "us-east"
}
]Two failures, two meanings
A null status with a transport error is a different fact from a 503. Both are failures to the detector; only one of them is a response. The artifact keeps the distinction, because a vendor reading it will ask.
Confirmation
Persistence is the honest signal when there is one vantage point.
There is one observation point, so there is no second opinion to appeal to. A fault is therefore confirmed by persistence: the same probe failing 2 checks in a row.
This is the part of the methodology most often misdescribed, by RELIASTRA included: an earlier version of this site claimed regional agreement for a detector that never had a region to agree with. The rule identifier, its threshold and its reason string now travel with the incident and into the record, so the claim and the mechanism cannot drift apart again.
The full methodology →Opens an incident
single.consecutive_failures · threshold 2started_at is the first failure of the qualifying run, so the window covers the outage rather than the check that noticed it.
Resolves an incident
single.consecutive_successes · threshold 2Resolution means this path answered successfully twice. It is not a vendor confirmation and not a claim that the cause was fixed.
Records without declaring
below the thresholdA failure run that never reaches the threshold stays in the record as observations. It opens nothing and is not hidden.
Attribution
Arithmetic, printed with its weights.
A reader who disagrees with a verdict should be able to recompute it. Every weight below is public, and the version that produced a result is stamped on the result.
| Signal | Weight | Question it answers |
|---|---|---|
| Temporal overlap | 0.20 | Did the dependency degrade inside the incident window? |
| Endpoint overlap | 0.25 | Was the failing endpoint one this dependency serves? |
| Latency correlation | 0.25 | Did latency move with the failures? |
| Error pattern | 0.15 | Are the errors one coherent class, or several? |
| Infrastructure baseline | 0.15 | Were RELIASTRA’s own probes healthy while this happened? |
Classification
A score is an alignment between two timelines. It is not proof of causation, and no surface in this product describes it as one.
Scope
What this product does not do.
Probes are issued from 1 observation point today, on a 300-second interval by default. Every page that reports a measurement says which window it covers and how many observations stand behind it.
It does not watch your infrastructure.
It watches the external services your infrastructure calls. Your own hosts, containers and databases are somebody else’s product.
It does not read response bodies.
The probe reads status and headers and closes. No payload ever reaches storage.
It does not see inside the vendor.
It measures the path it called from. Vendor-internal state, other customers and other regions are outside what this data can establish.
It does not backfill.
A missed probe is missing. The record says so rather than reconstructing it.
It does not publish your dependencies.
The observatory covers endpoints RELIASTRA measures as its own public record. Customer dependencies are never included.
Integrate
Reach it from where the work already happens.
The console renders the same objects the API returns. Nothing is available in one and not the other.
One endpoint you already depend on is enough to judge this.
Add it, watch the observations accumulate, and read the detector’s first decision. The trial needs no card.
This page replaces /dependency-monitoring and /external-dependency-intelligence. Evidence moved to /product/evidence, and the public index is now the observatory. Old URLs redirect permanently.