Run the demo stack

The demo is a self-contained stack: a small api-server (Prometheus metrics, request logs, fault injection), Prometheus, and a traffic generator — the upstream systems NavFlow ingests from. NavFlow runs on your machine and reads from the stack exactly as it would read from your real systems: three sources, one saved view, two live triggers, and a fault injector to cause incidents on demand.

Everything is two files you can curl — no repo checkout needed.


 demo stack (docker)                     NavFlow (installed locally)
 ┌───────────────┐  scrape   ┌──────────┐
 │  api-server   │◄──────────│Prometheus│◄─── metrics (:9090 PromQL)
 │  :8080        │           └──────────┘
 │  /metrics     │──logs────────────────────── docker logs
 │  /demo/inject │  (fault injection)          → one correlated timeline + triggers
 └───────────────┘
        ▲ traffic-generator

Start the stack

One compose file — the api-server image is prebuilt, and the Prometheus config is inlined:


curl -O https://raw.githubusercontent.com/glassflow/navflow/main/demo/docker-compose.yml
docker compose up -d              # api-server + prometheus + traffic

Give it ~10s, then check it’s alive:


curl -s localhost:8080/api/stats                  # {"ok": true, ...}
curl -s 'localhost:9090/api/v1/query?query=up'    # prometheus is scraping

Run NavFlow against it

Install NavFlow the normal way (not in Docker) and seed it with the demo catalog — from any directory:


uv tool install navflow          # or: pipx install navflow
 
curl -O https://raw.githubusercontent.com/glassflow/navflow/main/demo/catalog.demo.yaml
NAVFLOW_CATALOG=catalog.demo.yaml navflow up

The console opens at http://127.0.0.1:8787 with everything configured: three sources (prometheus, docker_logs, alerts) all keyed api-server, a service_timeline view over them, and the error_spike and slow_responses triggers watching it.

The catalog seeds only while your catalog is still empty. If you’ve run NavFlow before, point --data-dir at a fresh directory (or pass a fresh NAVFLOW_DB).

Look around

Explore — pick the api-server entity and watch metrics, logs, and alerts merge into one time-ordered timeline. Flip Agent view to see the exact read an agent gets over MCP.
Views / Triggers — service_timeline is the saved read; error_spike and slow_responses are watching it.

Cause an incident

Flip a fault by POSTing a scenario to the api-server:


curl -s -XPOST localhost:8080/demo/inject -H 'content-type: application/json' \
  -d '{"scenario": "error_spike"}'

error_spike — 5xx storm → the error_spike trigger fires
latency — p99 > 1s → the slow_responses trigger fires
dependency_outage — DB down → 503s + a dependency_up=0 metric
clear — roll back, faults cleared

Watch it land in Explore (the timeline turns red) and, once an agent is subscribed, in Agents → Trigger dispatches.

Ask an agent about it

With an agent connected, the incident is a question away:

Use navflow: what happened to api-server in the last 15 minutes?

The agent reads the correlated timeline — the 5xx storm, the alert, and the surrounding logs and metrics in one response.

Stop


docker compose down              # from the directory with docker-compose.yml

Files

Both live in demo/ in the repo:

docker-compose.yml — the whole stack, self-contained (prebuilt api-server image, Prometheus config inlined).
catalog.demo.yaml — NavFlow’s view of the stack (sources, views, triggers).

The repo also has the api-server source (demo/api-server/), a build override for hacking on it, and inject.sh, a wrapper around the inject call above.