Ongrid: an ops agent that reads topology before it answers

The gap Ongrid is aiming at: evidence gathering, not alerting

Alerting is a solved problem for most teams. Prometheus fires, Alertmanager routes, a pager buzzes. What is not solved is the fifteen minutes after the page, when an engineer opens four browser tabs, greps Loki, guesses which service is upstream of the failing one, and asks in chat whether anyone touched the deploy pipeline. Ongrid targets that window. The README describes it as an ops AI Agent that understands your infrastructure, finds the root cause, and fixes it, right from Slack or Telegram. The audience is the on-call engineer and the SRE team that owns the observability stack, not the platform team shopping for a hosted SaaS. The repository is Go with a TypeScript and React front end, licensed AGPL-3.0, and the install path assumes you have a Linux server you control. The pitch is narrower than the tagline suggests: it is a correlation and retrieval layer over telemetry you already collect, with a chat interface on top.

Coordinator, specialists, and the topology walk that produces an answer

The architecture visible in the README is a coordinator agent that dispatches to specialist sub-agents, described as SRE, network and DB. Separately, an investigator process can be spawned by an alert; that investigator spawns an RCA worker and writes the resulting cause back to chat. The RCA path is stated to walk topology, correlate metrics, logs and traces, and pin the why to a source-code line. That last claim is the load-bearing one. Pinning a cause to a source line requires the agent to have indexed your repositories, which is what the Knowledge Vault section describes: runbooks, notes, incident history and repositories indexed so humans and agents search the same operational context. The topology map is the other half, giving a dependency graph and blast radius so a failure can be traced through the affected service graph. Kubernetes resources are mirrored into that topology, and network devices are discovered from Edge hosts, verified over SNMP, and mapped to hosts. So the data flow is: telemetry and inventory in, topology graph built, agent walks the graph from the symptom, retrieves matching code and runbook context, and emits a cited analysis. Whether the source-line pinning holds up on a polyglot monorepo is not something the README addresses, and I would treat that claim as the first thing to test rather than the first thing to trust.

Zero inbound ports, and what the Edge dial-out actually buys you

The design choice with the most operational consequence is the Edge model. The README states there are zero inbound ports: the edge dials out, so no port 22, 80 or 443 needs to be open on hosts. Browser SSH is described as a reverse-tunnel shell into any host, with no keys and no jumpbox, and every session audited. For teams that have fought to keep SSH closed on production subnets, this is the reason to look at Ongrid at all. It also constrains you. Anything the agent inspects must be reachable from an Edge host, and the Edge process must be able to reach the control plane. If your monitored estate sits behind a network segment that permits no outbound traffic, the model does not degrade gracefully; it simply has nothing to dial. The host tooling is described as read-only, a bash sandbox plus 26 or more inspection tools, with every call audited. Read-only is a meaningful boundary, and it is also the reason the product cannot be sold as automatic remediation. The tagline says it fixes things. The feature list says read-only host tools. Those two statements sit in tension, and the write gate and approval workflow in the product tour is presumably where the resolution lives.

Getting it running: the tarball, install.sh, and what you must supply

Installation is deliberately plain. Download the release tarball for your architecture (linux-amd64 or linux-arm64), extract it, and run the installer as root. The README gives this exactly:

wget https://github.com/ongridio/ongrid/releases/download/v0.15.2/ongrid-v0.15.2-linux-amd64.tar.xz tar -xf ongrid-v0.15.2-linux-amd64.tar.xz && cd ongrid-v0.15.2-linux-amd64 sudo ./install.sh

For arm64, substitute ongrid-v0.15.2-linux-arm64.tar.xz. For mainland China, the README offers a CDN mirror at ongrid.cloud/dl/ with the same filenames. Supported hosts are listed as Ubuntu 22.04+, Debian 12+, and RHEL or Rocky 9. The README says install.sh brings up the full stack, and that stack includes Prometheus, Loki, Tempo and Grafana wired together, with the agent writing the queries. Model selection is bring-your-own: Anthropic, OpenAI, GLM, DeepSeek, Gemini and Kimi are named, with hot routing between them. Chat channels are Slack, Telegram, Larksuite, DingTalk and WeCom, with per-channel locale. External MCP servers can be registered and their tools exposed to chat agents and workflows. What the README does not give is the configuration surface: there are no documented config keys, no environment variable names, no example YAML for provider credentials or channel tokens. That is a real gap for anyone evaluating this in an afternoon, and it means the installer output is your documentation until you find the generated config on disk.

Where Ongrid is the wrong tool

Three cases stand out. First, if you are not already collecting metrics, logs and traces, Ongrid is the wrong starting point. It correlates telemetry; it does not create it. The bundled Prometheus, Loki and Tempo stack helps, but you still need instrumented services and an OpenTelemetry or scraping story before any RCA output is worth reading. Second, if your organisation cannot accept an LLM provider seeing incident context, the bring-your-own-model feature does not help unless one of the offered providers is one you can host or contract with under acceptable terms. The README names commercial providers and does not document a local model path. Third, if your incidents are mostly about coordinating humans (who is awake, who owns this service, has anyone paged the database team), Ongrid's value is low because that is a paging and ownership problem, not a correlation problem. There is also a subtler failure mode: an agent that confidently pins a root cause to a source line is worse than no agent if the pin is wrong, because it anchors the responder. The README describes the RCA output as evidence-backed with concrete next steps, but evidence quality depends entirely on how complete your topology graph is. Sparse topology produces confident, wrong answers.

How it differs from Grafana's own incident tooling

The obvious comparison is Grafana, since Ongrid ships Grafana and reads the same datasources. The difference is where the reasoning lives. Grafana gives you dashboards, alert rules and, in its newer incident products, a place to record and coordinate a declared incident. The human still reads the graph and forms the hypothesis. Ongrid inverts that: the agent forms the hypothesis and the human reviews it, with the topology walk and the Knowledge Vault retrieval doing the work a senior engineer would do by hand. The practical consequence is that Grafana is a tool you look at, and Ongrid is a participant in the channel. That also means the failure modes differ. A misconfigured Grafana panel shows you a wrong number and you notice. A misconfigured Ongrid posts a plausible root cause into Slack and someone acts on it. If your team's instinct is to distrust generated analysis by default, Ongrid will be an expensive way to get a second opinion. If your team is small and the on-call rotation is thin, the trade may be worth it, because the alternative on a bad night is one tired engineer doing the same walk manually.

Maintenance, upgrades, and the AGPL-3.0 question

The release cadence visible in the material is fast: v0.15.0 on 2026-09-03, v0.15.1 and v0.15.2 on 2026-09-07. Four releases inside a week at the 0.15 line means the project is still moving, and it means you should expect to upgrade rather than install once and forget. The README does not document an upgrade procedure, a migration path for stored topology or index data, or a rollback. That is a gap worth flagging: pin the tarball version you install, keep the extracted directory, and read the release notes for each version before you move, because nothing in the supplied material tells you whether v0.15.2 changes on-disk state relative to v0.15.0. On licensing, the project is AGPL-3.0. The clause that matters for internal tooling is the network interaction provision: if you modify Ongrid and let users interact with it over a network, the AGPL requires you to offer those users the corresponding source. Running it unmodified against your own infrastructure is the ordinary case and does not trigger that. Forking it and exposing the fork to your engineering org does. This is not legal advice, and if you plan to embed Ongrid in a product you sell, that question belongs with your counsel, not with a README.

Editorial conclusion

Adopt Ongrid if you already run Prometheus, Loki and Tempo, you have an Edge host you can install an agent on, and you want alert-driven investigation to land in the same chat channel where your on-call rotation already lives. Do not adopt it if you need a vendor to hold your credentials, if you cannot run a long-lived process on or beside your hosts, or if your incident response is mostly about paging humans rather than gathering evidence. Before rollout, verify three things in a staging install: that the Edge dial-out path reaches your control plane from the network segment your monitored hosts sit in, that your chosen model provider is reachable from the control plane and not only from your laptop, and that the AGPL-3.0 network-copyleft clause is acceptable to whoever owns your internal tooling policy.

Official sources

1. License: AGPL-3.0
2. ongridio/ongrid on GitHub
3. Project website
4. README
5. Releases