Health

The Health page is a live status board for your Scrydon deployment. Open it from Settings → Platform → Health. It runs a battery of read-only checks and shows infrastructure status and offers explicit tests of configured extension capabilities.

What you see

• Infrastructure banner — a verdict for infrastructure: Infrastructure checks passed, Degraded, or Outage.
• Checks table — one row per individual check, which you can search (type to filter) and sort. Each row shows what is being checked, a status, and a Context column with the detail (the error text, the address probed, and response time). The Type column groups the checks:
  • Reachability — is each Scrydon service responding? (OK · Degraded — answered but something is off · Unreachable — no response · Skipped — not configured in this environment).
  • Dependency — is each service's backing store (for example its database) up?
  • M2M — can Scrydon's internal services authenticate to one another? (OK is healthy; Denied means an internal permission is mis-configured.)
  • Migration — does each service's database have every update it expects? Pending migrations means an upgrade step was not run — the row lists exactly which database updates are missing, so your operations team knows what to apply. Each row can also be expanded to show which migrations have already run. (A common cause of problems after an upgrade is a forgotten migration step; this check makes it visible.)
  • Isolation — what the runtime plane (the component that runs agents and untrusted workflow steps in isolated single-use pods) has verified it can provide on this cluster. The first row confirms the plane answers with its capability attestation; the remaining rows show each isolation tier (microVM, mediated, hardened) as Available or Unavailable, plus the raw facts behind the decision — whether the node exposes the /dev/kvm hypervisor device, and whether a Kata RuntimeClass exists and selects a Ready node. Unavailable is a truthful capability statement, not an error for unrelated workloads: a cluster without a Kata node pool may expose the weaker hardened tier for a separately qualified non-Agent workload. With standard-Agent isolation required, the Agent is unavailable on that cluster and never automatically downgrades to hardened or host execution. An organization admin can explicitly select audited in-process Agent execution under Settings → Platform → Compute; that opt-out is not an isolation tier and is not covered by the capability attestation. An enabled but unreachable runtime plane degrades the overall verdict because isolation-enabled Agent execution fails closed while it lasts. See Untrusted step isolation for how the tier is chosen per step.

Re-running the checks

The page checks infrastructure when it opens. Press Re-run checks at any time to probe again — useful while you are bringing a deployment up or after changing configuration.

Check configured extensions

Open Extensions to check what your organization has configured. The tab reads like the Infrastructure tab: a summary banner, then one row per check with its Type, Status and Context. Re-run checks in the page header re-runs whichever tab you are looking at.

Free checks run on their own

Opening the tab runs only free checks, shown with the type Configuration:

• Connections, Capability configuration and Default policies inspect stored configuration and the installed catalog: configuration format, endpoint URL syntax, explicit default policies, connection references, environment scope and model allowlists.
• One row per configured HTTPS endpoint performs a fresh TLS handshake and verifies hostname, certificate trust and validity. Public endpoints use DNS pinning; private destinations, plain HTTP, credential-bearing URLs and missing endpoints are reported as unverified. The handshake has a five-second deadline.

These checks send no provider request, discover no models and read no credentials. A Passed free check does not verify credentials, automatic model selection, deployments or dispatch routing; that is what a live test is for.

All accessible workspace environments are checked by default; use the Environment selector to narrow that. The same check in several environments is one row. Its status is the worst of its environments, so a pass never hides a failed or untested sibling. Expand the row to see each distinct finding once, worst first, with the environments it affects. Search matches labels, models, environments and provider errors; Filter narrows by type or status.

Live tests cost money, so you run them one at a time

A live test sends one small synthetic request to the provider. Nothing is sent until you click that test, and there is no bulk run.

1. Estimate cost · free resolves the target, checks its TLS endpoint and prices the workload. It may read credentials and discover models, but generates nothing. A default whose qualified model resolves to a different target fails here, before any paid request.
2. The button then shows the price, for example Run test · ≈ $0.00077, or Run test · cost unknown when the catalog has no matching rate. Clicking it is your consent for that one request. An estimate is not a billing cap: provider minimums and governance checks may add cost.

Essential coverage, the default, lists one test per configured default: the cheapest operation that proves the default works. All tests adds every connection and stored model, streaming variants, and image and video generation.

Workloads are fixed and small: at most 128 LLM output tokens, one short embedding, a clip under two seconds, one sentence, one OCR page, one 1024 × 1024 image, or four seconds of 720p video. Provider retries are disabled. Default tests follow normal selection; connection tests are pinned to that exact connection and model. After a run the row shows latency and, when the provider reports usage, the tokens and their estimated cost.

A live Passed means the request completed and its output passed validation. Failures carry safe provider reasons such as endpoint_untrusted and model_not_found. Tools, webhooks, selectors, triggers and realtime media need resource-specific fixtures and are not live-tested.

Estimates and test tickets expire after 15 minutes, and a changed target needs a new estimate. A success is remembered for 15 minutes for the same caller, environment and unchanged configuration; Retest runs it again. Results are point-in-time evidence, not monitoring history. Cancel stops loading or signals the active request; work the provider already accepted may still complete and be charged. The debug package continues to contain infrastructure diagnostics only.

When something is red

A red result points your operations team at the failing service or dependency. Share what you see (which service, which status) with your administrator or Scrydon support — combined with Download debug package in this page's header, it gives a precise starting point for diagnosis.