> ## Documentation Index
> Fetch the complete documentation index at: https://artemiscity.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitoring dashboard

> Operator view of governance state and Prometheus alerts in the Artemis City dashboard, backed by two independent read paths so the page stays useful even when the metrics stack is off.

The **Monitoring** page (under **Inspect → Monitoring** in the dashboard) is the single place operators check governance health and the live metrics stack. It reads from two deliberately independent sources through the FastAPI boundary the frontend already uses, so the browser only talks to one API origin and the page stays useful when Prometheus is down.

## When to use this

* You need a fast read on which agents are quarantined or suspended and why, without running SQL against the governance stores.
* You want to see which Prometheus alert rules are firing, which scrape targets are healthy, and how those correlate with the durable governance snapshot.
* You are running Artemis City in SQLite-only mode with the monitoring stack switched off, and still want the same governance view.

## Where the data comes from

The page composes two endpoints, both behind the existing `X-API-Key` auth pattern:

| Endpoint                                                                       | Source                                                                                             | Availability                                                                                  |
| ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| [`GET /api/monitoring/governance`](/api/api-reference#get-governance-snapshot) | SQLite governance stores, read with the same strictly read-only access as the `/metrics` collector | Always available, including SQLite-only mode with the monitoring stack down                   |
| [`GET /api/monitoring/prometheus`](/api/api-reference#get-prometheus-snapshot) | Prometheus HTTP API, proxied server-side                                                           | Available when the Prometheus stack is running; degrades to `available: false` when it is not |

The page reads live from the systems of record each refresh. Nothing on the server caches a copy that could drift from the SQLite stores or Prometheus.

## What the page shows

The page auto-refreshes every 30 seconds, matching the Prometheus scrape interval.

**Stat tiles**

* Quarantined agent count
* Suspended agent count
* Sentinel alerts currently firing
* Governance-store readability (agent registry and Hebbian weights)
* Prometheus connectivity

**Prometheus alerts**

A table of alert rules from `/api/v1/rules`, with the current state (`inactive`, `pending`, `firing`), severity label, and every active alert instance with its labels and activation time. Paired with a scrape-target health table drawn from `/api/v1/targets` (job, health, scrape URL, last error).

**Agent governance**

A per-agent row from the registry store: trust score, tier, status, and violation count. Agents that have not been scored yet render as `unscored` rather than `0.00`, so an unmeasured agent is never confused with a low-trust one.

**Hebbian Sentinel scopes**

A row per `(agent, task_type)` scope tracked by the Hebbian Sentinel: whether the alert is active, the current oscillation rate versus the configured threshold, and the sample count backing the reading.

## Degraded mode

If the Prometheus stack is not running, `GET /api/monitoring/prometheus` returns `{ "available": false, ... }` instead of an error. The Monitoring page then hides the alert and target tables, keeps rendering the durable governance snapshot from SQLite, and shows a hint that the metrics stack is off. The governance snapshot never depends on Prometheus being up.

## Configuring the Prometheus proxy

The FastAPI kernel reads `ARTEMIS_PROMETHEUS_URL` at startup to know where to reach the Prometheus HTTP API for `GET /api/monitoring/prometheus`.

* **Docker Compose.** The kernel service already sets `ARTEMIS_PROMETHEUS_URL=http://prometheus:9090`. No action needed for the default stack.

* **Local development without Compose.** Export the variable before starting the kernel:

  ```bash theme={null}
  export ARTEMIS_PROMETHEUS_URL=http://localhost:9090
  ```

* **Timeout.** Set `ARTEMIS_PROMETHEUS_TIMEOUT` (seconds, defaults to `3`) if your Prometheus is slow to respond. The proxy treats any HTTP error, invalid JSON, or timeout as "stack unavailable" and returns `available: false`.

The browser never needs to reach `:9090` directly. All Prometheus traffic goes through the FastAPI boundary using the same API key the rest of the dashboard already uses.

## Related

* [Governance metrics](/Documentation/governance/metrics) — the underlying indicators surfaced through the `/metrics` collector and the governance snapshot.
* [Trust scoring](/Documentation/governance/trust-scoring) — how the trust score, tier, and status on each agent row are produced.
* [API reference: monitoring](/api/api-reference#monitoring-api) — request and response shapes for both endpoints.