Show the provider status page link when a request or health check fails

[FabioLeitao]

Problem

When a provider request fails with a network error, a timeout or a 5xx, Zero tells the user what failed but not where to check whether the provider itself has an incident. The user has to know the vendor's status page, and an agent running inside Zero has no way to tell "I could not reach this host from here" apart from "the provider is down".

Concrete case from my own use (Zero 0.10.0, built from my fork at upstream ce2fcffa): an agent ran a status-check command inside its sandbox, got no response, and reported GitHub, Anthropic and Cursor as all down. Run directly from a normal shell a few minutes later, the same check showed all three operational. My reading is that the sandboxed command simply had no network access, but I did not confirm that from the session log. Either way, nothing in Zero separated the two cases or pointed at a source of truth.

Behavior I'm proposing

Smallest version, with no network access and no parsing:

• Add an optional StatusURL (static, https:// only) to the provider catalog descriptor. Empty for local runtimes and custom endpoints, and left empty wherever it is not confirmed.
• Show it only when a failure is of the network, timeout or 5xx kind: in zero doctor, zero providers check, and the TUI error line for the failed request. Never for configuration or authentication errors, where a status page is irrelevant.
• Word the message so that "could not reach " and " reports an incident" are different statements. The link is a pointer, not a verdict.

Why it belongs in Zero

Zero already has the pieces: providerhealth categorizes failures (for example network vs config), PR #233 added the clear "model host is unreachable" error, and zero doctor --connectivity probes the endpoint. This adds the last step, "and here is where the provider publishes incidents", at the cost of one string per catalog entry. It is provider-agnostic, works offline, and cannot be wrong in a way that misleads: it does not claim anything about the provider's state.

Alternatives considered

• Fetching and parsing status APIs (for example Statuspage api/v2/status.json). Several providers answer non-browser clients with 403, formats differ per vendor, and it means an automatic outbound call to a third party, which seems out of character for a sandbox-conscious agent. That would be a bigger decision, so I am deliberately not proposing it.
• An automatic "outage" verdict or retry/fallback policy. Out of scope here.
• Doing nothing and leaving it to documentation. Cheap, but it does not help at the moment of failure.

Status

Not implemented. I searched issues, PRs and Discussions here for status pages and outage hints and found nothing, though a text search can miss other wording. I can prototype it on my fork and report back if there is interest, and I will not open an issue or PR unless the core team wants one.