Handle source outages

Separate service conditions from token conditions #

A provider timeout describes the service's ability to read a source. It does not prove that the token is paused or the chain sequencer is down. Those findings require the corresponding supported evidence.

When part of a report is unavailable #

Open the affected check and panel. They name the missing evidence and distinguish a source failure from an unattempted or unsupported check. Other reads can still show the evidence they obtained; a failed token-name call does not discard a successful code or decimals read.

Project identity requires both reviewed sources to match in the current observation. An unavailable website or GitHub source prevents a complete match. A prior review or previous receipt is never substituted for the missing response.

PeelSignal never substitutes a demo fixture or treats a failed read as a healthy default.

When the explorer or market provider has a gap #

The explorer and market lookups run independently from contract reads. A blocked explorer API, provider quota, timeout or invalid response remains an unavailable source. The report can still show the RPC metadata and any other successful source.

A successful market lookup with no accepted exact-address pairs is a different result. It means this provider returned no matching indexed pairs for the observation; it does not establish that no market exists. The scanner never replaces a failed live lookup with an old pair or a demo.

When a project source changes #

A website or GitHub profile that now publishes a different address, chain or account link produces explicit mismatch evidence. An unreadable response records an unavailable source. A changed page layout can also stop the reviewed parser from establishing a match.

Open both source details and compare their timestamps, fields and recorded content hashes. A successful HTTP request alone does not make identity evidence match. Review changes through Source review; repeatedly retrying cannot repair a changed profile.

When GitHub limits project checks #

The public GitHub API quota is shared by requests from the server’s IP address. A 403 or 429 rate-limit response can temporarily prevent a complete project identity match. The scanner records the failure and respects the provider’s retry or reset time. Read GitHub’s rate-limit documentation .

The operator can supply the server-only GITHUB_READ_TOKEN for the fixed reviewed GitHub endpoint. It is not sent to project websites or placed in receipts. A quota failure never changes into a successful cached identity result; see Project identity.

When a coverage refresh fails #

Coverage keeps the latest failed attempt separate from any last successful receipt. Open the earlier receipt only as a historical observation. Its timestamp and expiry remain unchanged.

Source details distinguish rate limits, timeouts, invalid responses and validation failures when the source supplies enough information. The service delays retries, bounds their count and shares refresh work across visitors.

When the request cannot finish #

Input errors, service limits or a receipt-storage failure can stop a request before a usable receipt exists. Read the message and retry only after correcting the input or allowing the service to recover.

Do not assume a receipt was saved unless the service provides its permalink.

Retry with a new observation #

Recheck requests new evidence and creates a new observation. The earlier receipt remains unchanged. Avoid repeatedly submitting the same request while a source is unavailable.

The service uses bounded requests rather than waiting indefinitely. A later retry can remain Unknown if the source still fails.

Read the recovery evidence #

For supported sequencer checks, a response after recovery still needs to satisfy the reviewed recovery rule. PeelSignal does not guess a grace period or use a generic network-health badge to replace that evidence.

Check Coverage for the supported method and Unknowns for the status distinctions.