Skip to main content
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: 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:
  • 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.
  • Governance metrics — the underlying indicators surfaced through the /metrics collector and the governance snapshot.
  • Trust scoring — how the trust score, tier, and status on each agent row are produced.
  • API reference: monitoring — request and response shapes for both endpoints.
Last modified on August 17, 2026