ProvelyProvely records two things. It records whether a provider answered our own reads. It also reads what the provider publishes about itself. Neither figure can change a verdict.
A status feed never decides a verdict. A verdict rests on evidence that operators evaluate. A status page is second-hand text that an interested party writes, and Provely treats it as data. It explains an answer. It never produces one.
Where does each figure come from?
| Figure | Source | How independent | What it proves |
|---|---|---|---|
| What we observed | The observation records of verification attempts | First-hand | Whether the exact path a verdict rests on answered us. |
| What the provider reported | The status document that the provider publishes | Second-hand | What the provider chose to say about itself, at the time we read it. |
Prefer the first row. Our reads describe the network path, the credential, and the endpoint that the contract names. A provider status page is often late, and it is often narrower than the outage. It can say "all systems operational" while the endpoint your contract reads returns nothing.
What does each bar of the strip mean?
| Bar | What we saw |
|---|---|
| Operational | Every read in that period arrived and answered. |
| Degraded | Some reads did not arrive, or arrived with no usable answer. |
| Outage | Most reads never arrived at all. |
| No data | We made no read of this provider in that period. |
A period with no read is never drawn as healthy. Zero reads is not proof of health, and a bar must never claim more than the reads behind it.
What does uptime change about a verdict?
Nothing. Read the verdicts and retries page for what each verdict permits. Uptime adds one sentence beside a verdict that is still open, and it adds a link to the provider status page. The verdict, the reason code, and the retry rule do not move.
| Verdict | What uptime adds | What stays the same |
|---|---|---|
| PENDING | A sentence that says whether our reads arrived. | Wait. Never retry the action. |
UNVERIFIABLE, evidence_unavailable | A sentence that says whether the provider answered us, and the provider status link. | Retry the verification only. |
| CONTRADICTED | Nothing. No outage softens a contradiction. | Stop. Ask a person. |
| VERIFIED | Nothing. | The evidence already satisfied the contract. |
How does Provely read a provider status page?
- A background worker reads the document that the provider publishes. Nothing on a request path waits for it.
- A source reads one shape of document. The configuration binds each service to one source by name, so a new provider needs one configuration entry.
- A document that is absent, slow, or malformed records the indicator
unknown. Provely does not guess. - Every string from the document is cut to a length, cleaned of control characters, and kept as text. A link that is not an https URL is dropped.
Can a provider status page make my operation verify?
No. The verification runtime holds no dependency on the code that reads a status page, so it cannot reach one. A status report annotates an answer that the runtime already decided.
Why does the strip show no data when the provider says it is up?
The strip counts our own reads. A period with no verification attempt holds no read, so Provely records nothing and claims nothing.
Does a permission failure count as a provider outage?
No. A read that arrives and is refused counts as degraded, never as an outage. A refusal is far more often a credential fault of ours.
Where do the status page addresses come from?
They are configuration, with defaults that a person confirmed and dated. A deployment changes any of them without a code change.