Platform health
Admin → System → Platform health shows whether Qry's services are working now and what failed in the last hour, day or week. It reads Qry's own records and the cluster where Python runs. It needs no Prometheus or Grafana, so it shows the same on every installation. The page refreshes itself every 30 seconds.
Services now
One row per service, each with its state (healthy, degraded, down) and its figures:
| Service | What is checked |
|---|---|
| Chat workers | Turns waiting in the queue and how long the oldest has waited; the share of failed turns in the window. A turn waiting more than 30 seconds degrades it, more than 2 minutes marks it down. |
| Python execution | Pods in the python-execution namespace: running, waiting to start, and what a waiting pod waits for (no node with room, the image being pulled). A pod pending over a minute degrades it, over five minutes marks it down. Also the pods' CPU and memory limits and the warm pool. |
| Background workers | The Celery workers that answer and the tasks queued for them (scheduled tasks, Lakeflow, maintenance). None answering marks it down. |
| Lakeflow | Pipelines that have stopped loading on schedule and failed runs. |
| Database | Latency, connections against the server's limit, and a transaction left idle for more than five minutes. |
| Redis | Latency and memory against its limit. |
Python execution reads Not configured when Python does not run on Kubernetes (it then runs in the model provider's sandbox).
Activity
Chat turns and their duration (95th percentile, and how long they queued), Python runs and how long their pods took to start, scheduled tasks and Lakeflow runs — with a chart of Python runs or chat turns over time.
Failures
Every failure in the window, grouped by cause (how many times, the first and last time, how many users), or one by one in time order. Opening one shows what it means and what to do.
| Failure | What to do |
|---|---|
| No room in the cluster | No node had the CPU or memory the pod asks for. The reason is the cluster's own, for example 0/3 nodes are available: 3 Insufficient memory. Add capacity, or lower the Python CPU and memory limits in System configuration. |
| Pod never started | The pod was created but never ran. The events of the python-execution namespace say why. |
| Image could not be pulled | Check the registry credentials (the pull secret) and that the executor image exists. |
| Out of memory | The code used more memory than the pod's limit. Raise the limit, or ask for less data. |
| Timed out | The code ran longer than the execution timeout. |
| Turn failed | The chat turn ended with an error: the model provider's (rate limits, credentials, an unavailable model) or Qry's. |
Code errors — the assistant's own code ending with an error — are hidden by default: nothing is wrong with the platform. The Code errors filter shows them.
Chat turns and Python runs are recorded from the version that added this page and kept for 30 days. Scheduled tasks and Lakeflow runs come from their own history.
With Prometheus
If your cluster runs Prometheus with kube-state-metrics (for example kube-prometheus-stack, as in Qry's monitoring/ guide), the page also shows what Qry cannot see from its own namespace:
- Cluster: memory and CPU reserved and in use on each node, and whether a Python pod of the configured size still fits on it. When no node has room, Python execution reads as down before the next run gets stuck.
- History of the execution pods in the window, including from before this page existed: pods that found no room, out-of-memory kills, image pull failures, crash loops. A chart shows running and pending pods over time against the memory reserved in the cluster.
- Datasources and models: queries, errors and 95th-percentile time per engine, and calls, errors, time and cost per model.
- API: requests, server errors and latency.
The cluster figures cover the whole cluster, every installation on it. Datasource, model and API figures are this installation's only, even when one Prometheus watches several.
Qry finds Prometheus on its own at http://kube-prometheus-stack-prometheus.monitoring.svc:9090. If yours is elsewhere, set Prometheus URL in Admin → System Configuration → Application. Without one, these sections are hidden and the rest of the page works as usual.
Installations that scrape Qry also get qry_platform_events_total{kind, outcome, source} and qry_python_execution_wait_seconds, the same outcomes as metrics.