Check System Status and recover from errors
Use DVARA Flightdeck to separate a control-plane problem from a Gateway or provider problem. The readiness probe tells your orchestrator whether Flightdeck can serve control-plane work; Operations → System Status shows whether Flightdeck can reach the DVARA LLM Gateway and what that Gateway reports.
Not included in DVARA Open Source.
Check Flightdeck readiness first
Request the Flightdeck readiness endpoint:
curl --fail --silent \
https://<flightdeck-host>/actuator/health/readiness
A ready response is deliberately small:
{
"status": "UP"
}
Flightdeck readiness covers its application readiness state and PostgreSQL connection. It does not depend on Gateway connectivity. This is deliberate: if a Gateway is unavailable, Flightdeck must remain reachable so an operator can inspect the outage and repair configuration.
| Signal | What it answers | Includes Gateway reachability? |
|---|---|---|
Flightdeck /actuator/health/liveness | Is the Flightdeck process alive? | No |
Flightdeck /actuator/health/readiness | Can Flightdeck serve control-plane requests and reach PostgreSQL? | No |
| System Status | Can Flightdeck reach the Gateway, and what health does the Gateway report? | Yes |
Do not change readiness to require the Gateway. That would remove Flightdeck from service during the outage it is meant to help you investigate.
Read the System Status result
Open Operations → System Status. The page refreshes on demand and assigns one overall state:
| State | Meaning |
|---|---|
| Operational | Flightdeck reached the Gateway, and the Gateway reported no provider problem or operational warning. |
| Degraded | The Gateway is reachable, but at least one provider is unhealthy or unknown, the Gateway reports a warning, or its overall state is degraded. |
| Unavailable | Flightdeck could not obtain Gateway status, or the Gateway reported a down, unavailable, or failed state. |
Workspace roles see the overall Gateway state. Platform roles also see the Gateway version, mode, uptime, route count, reported warnings, and each provider's name, type, health, and capabilities. System Status does not expose credentials, dependency response bodies, or low-level exception details.
Provider health on this page is the Gateway's latest reported view. An unhealthy provider does not make Flightdeck itself unready; it changes System Status to Degraded so you can investigate the affected route or credential.
Know what works during a Gateway outage
When PostgreSQL and Flightdeck remain healthy, you can still sign in and use stored control-plane data. You can inspect workspaces, policies, routes, credentials, budgets, and existing audit evidence, and you can save configuration changes.
Live Gateway and provider panels cannot update until connectivity returns. Model, MCP, and A2A traffic depend on the health of their own Gateway plane, and a saved control-plane change cannot affect that traffic until the relevant Gateway reconnects and receives it.
Use safe error details
Flightdeck's error page shows an HTTP status, a safe explanation, the failed path when available, and a support reference. Use the status to choose the next action:
| Status | Meaning | First action |
|---|---|---|
400 | The request or form could not be understood. | Check the address and submitted values. |
401 | The session is missing or expired. | Sign in again. |
403 | Your role does not permit the action. | Confirm your workspace and role with an owner. |
404 | The page or record is no longer available. | Return to the relevant list and open the current record. |
409 | The record changed while you were working. | Reload, review the current state, and submit again. |
422 | One or more values failed validation. | Correct the highlighted values; no changes were applied. |
503 | The control-plane page is temporarily unavailable. | Retry once, then check System Status and readiness. |
500 | Flightdeck could not complete the request. | Keep the support reference and ask the operator to match it in the logs. |
Flightdeck returns the request correlation value in X-Correlation-ID and
shows it as the support reference on an error page. Record it before reloading.
Do not substitute a timestamp or a browser-generated request ID when the page
already provides the exact reference.
Collect evidence without collecting secrets
For a support request, collect the System Status state and check time, the affected Gateway plane or provider, the HTTP status, failed path, and correlation ID. An operator can then collect the matching Flightdeck and Gateway log lines and the readiness response.
Do not send API keys, access tokens, cookies, authorization headers, provider credentials, full configuration exports, or raw provider response bodies. System Status intentionally omits these values.
Follow the deployment recovery path
- For a local or Docker deployment, use Docker logs and health probes.
- For Kubernetes, use the pod and probe troubleshooting steps.
- For a managed cloud deployment, use the cloud health-check guidance.
- For configuration loading and recovery, see Operate runtime configuration.