Build your own AI SRE that resolves incidents in minutes, not hours.
Reads every source you run and serves your agent the correlated view it needs, in one call.
One correlated read per incident, not eight tool calls.
Around 1.3× cheaper than the alternative, and cheaper on every fault we ran.
MIT licensed
One daemon on your own infrastructure. Nothing leaves it.
Working in 30 minutes
Install the daemon, add two sources, connect your agent over MCP.
Cheap to run
One correlated read answers an incident, so the token bill stays small.
Scales with your systems
Runs fine on a laptop, and the same setup grows as you add services and sources.
Point it at the systems you already run.
- Prometheus
- Grafana
- NGINX
- PostgreSQL
- MySQL
- Elasticsearch
- Docker
- Jenkins
- OpenTelemetry
- Kubernetes
- Vercel
- GitHub
In-house and custom sources work too. Anything that can POST JSON is one config block, no SDK. See the full connector list, or ask for one.
Your agent asks one question because the context is already assembled.
NavFlow correlates events as they arrive, so the expensive work happens once in a database rather than on every incident inside a language model.
Every source is ingested once.
NavFlow polls or receives from each system you connect and stores every event whole. Nothing is summarised on the way in, so you can replay exactly what your agent read.
Events are keyed by entity, on one clock.
A log line, a deploy and an alert about api-server all land under the same key with one normalised timestamp. The alignment happens on write.
A view is the correlated read.
“Everything about api-server in the last 15 minutes” is a keyed, windowed view: one round-trip that returns real events, in order.
Triggers fire on live conditions.
Define a condition over the stream and NavFlow wakes your agent with the correlated context already attached.
Your agent does not just read NavFlow. It sets it up.
Everything the console can do is an MCP tool, so wiring NavFlow up is a conversation with the coding agent you already have open. It can see what is running on the box, profile a source's real fields before choosing a key, create the view, and set the trigger.
- inspect
See what is running, and what a source actually contains before you commit to a shape.
discover_docker()list_connectors()source_fields()catalog_describe() - create
Add a source, try it, then shape the view you want to read.
create_source()test_source()derive()update_view() - watch
Set a condition over the stream and choose who it wakes.
create_trigger()update_trigger()subscribe() - read
Pull the correlated timeline, and write back what was learned.
query()read()remember()
You do not need an external agent to see this work. A NavFlow agent is a prompt attached to a trigger, running inside NavFlow itself.
A prompt on a trigger
Write what you want looked at. The trigger decides when.
It reads the timeline
When the trigger fires it gets the correlated window, and can read wider before it concludes.
It writes a finding
The finding lands on that entity's timeline as a source of its own, and can post to Slack.
It reads and concludes. The actions stay with your agent.
Four steps to a working read path.
One daemon with an embedded store, on your laptop or a small VM. Connect an agent over MCP, point it at two systems you already run, and you have a read path working against your own stack.
Start the daemon
One process with an embedded store and a web console on localhost:8787, ready to take sources.
terminaluv tool install navflownavflow up# daemon + console on http://localhost:8787Point your agent at it
NavFlow speaks MCP, so anything that speaks MCP can read it: Claude Code, Codex, Claude Desktop, or your own loop through any MCP client. Or skip the wiring and create a NavFlow agent, which runs the reasoning inside NavFlow itself.
terminalnavflow mcp --transport streamable-http \--port 8788 --navflowd http://localhost:8787claude mcp add --transport http \navflow http://localhost:8788/mcp# navflow: connectedAdd your sources
In the console under Sources → Add source, where Discover proposes sources from what is already running. Or ask the agent you just connected; it can profile a source's real fields before you commit to a key.
ask your agent> use navflow: add my prometheus atlocalhost:9090, keyed by servicediscover_source("prometheus", …)source_fields("metrics")create_source("metrics", …)# or: Sources → Add sourceAdd a view, attach a trigger
A view is the correlated read you want: pick the sources and say what the key means. A trigger is a condition NavFlow checks over that view as events arrive, and when it fires the timeline is pushed to every subscribed agent. Both live under Views & Triggers.
ask your agent> use navflow: correlate metrics, logsand deploys by service, then wake mewhen 5xx passes 1/s for a minutederive(name="service_timeline",sources=["metrics", "api-logs", "deploys"],key_field="service")create_trigger(name="error_spike",view="service_timeline",condition={"aggregate": "max","field": "rate_5xx","predicate": "> 1.0","window": "1m"},cooldown="5m")
Keep it in git
Sources, views, triggers and agents are all one catalog file. Commit it and a fresh instance comes up configured, which is how you move a setup between staging and production or hand it to someone else.
It is imported on first boot when the store is empty. Set NAVFLOW_CATALOG_SYNC to re-import on every boot and make the file the source of truth.
What engineers ask before they try it.
Not here? Email hello@navflow.ai.
How we think about this. Essays and worked examples.
Open core was a licensing strategy. It needs to become an architectural one.
The enterprise tier was defensible because building it yourself was expensive. That clause just changed. Gating capabilities is a weaker strategy than it used to be; gating operations is a stronger one.
read →The lakehouse organized data for analysts. Nobody has organized it for agents.
Every data layer ever built assumed a human decides the shape of the data ahead of time and a human reads the result. Production agents violate both assumptions — and the next data layer will be authored, in part, by the agents that read from it.
read →Agents in production: what looks like a reasoning failure is usually a context failure
Your agent isn't hallucinating — it's reasoning correctly over the wrong inputs. What looks like a reasoning failure is usually a context failure, and context failures are fixable with engineering, today.
read →One read path, four incidents
The extended SRE benchmark: the same agent, with and without a data plane underneath.
read →Give your agent one place to look. Everything your systems emit, in one call.
Two commands and a source you already run.
Want the managed version instead? Join the cloud waitlist.