Why We Built Horizon: AI for Engineering Operations

Every engineering organisation we have worked with has the same two-layer problem. The delivery layer (Jira, sprints, releases) and the runtime layer (Kubernetes clusters, observability, incidents) belong to the same team and describe the same product, but they almost never speak to each other in the same place. Engineering managers stare at burndowns. SREs stare at Grafana. Nobody is staring at the line that connects them.

Horizon is our attempt to fix that. It is an AI-driven engineering operations platform that unifies Kubernetes observability, delivery intelligence, and AI-generated analysis of sprints, releases, and incidents. It started as an internal tool at one of our largest clients, grew into a real product, and is now in production across 7 Kubernetes clusters and 10+ tenants.

The Problem We Kept Running Into

Running a multi-cluster Kubernetes platform for a multi-tenant SaaS surfaces the same questions every week:

• Is the next release safe to ship, or is something in the sprint going to bite us in prod?
• Who actually owns this incident, and what did the last similar deploy look like?
• The sprint says we are on track. The cluster says otherwise. Which one is right?
• What does our team’s velocity actually look like once we strip out carryover work?

We tried solving these with off-the-shelf tools. The engineering intelligence vendors (LinearB, Faros, Swarmia) do Jira and git well, but they do not touch the cluster. The runtime tools (Komodor, internal developer platforms like Cortex or Port) see the cluster but do not understand delivery. Every team we know was running both, plus a custom dashboard, plus the bookmark to the Helm release history.

Nobody was answering the actual question: “Is what we are about to ship going to work?”

What Horizon Does Differently

Horizon was built around one principle: connect sprint reality to live cluster state, and let an AI explain what you are looking at.

Delivery intelligence with truth-telling. We ingest Jira at scale (boards, sprints, fix versions, issues, subtasks, absences, dev and QA splits) and produce sprint analysis that takes carryover work seriously. The Agile API tells you which issues actually moved across sprint boundaries; most velocity charts pretend that does not happen. We do not.

Runtime observability that thinks in tenants. Each Kubernetes resource (pods, deployments, ConfigMaps, ingresses, PVCs, RBAC) is browsable per cluster and per tenant. A custom health score per namespace combines pod state, restart counts, recent events, and deployment status into one number you can scan in a TV-mode dashboard.

Release tracker with a deploy confidence score. Every release gets a 0-100 score that weighs services-ready, prerequisites, regression results, and Jira completion. It is not a vibe, it is a number you can argue with. We also pull DORA metrics (deploy frequency, lead time, change failure rate, MTTR) directly from Helm history and incident records.

AI analysis, grounded in your data. Anthropic Claude and OpenAI both wired in. Per-sprint analysis (health, workload balance, dev and QA pipeline, risks, velocity comparison), per-epic analysis (workload, bottlenecks, stale tickets, release impact), and historical analysis across all 2026 sprints. The AI gets pull-based workflow context, board-specific terminology (a DevOps board talks about DevOps engineers, not “developers”), and the data needed to call out the things humans skim past.

Operational extras teams actually need. Cert calendar with auto-discovery of expiring TLS, MSSQL log analytics with severity filtering, QA test management with Playwright import, audit logging, OIDC, LDAP, and MFA, multi-tenant RBAC, and super-admin impersonation.

Where It Is Today

Horizon is in production at Scoop Technologies across 7 Kubernetes clusters and 10+ tenants. The whole platform is multi-tenant by design. Organizations, users, clusters, plugins, audit logs, AI cache, and sprint boards are all scoped by org from day one.

The tech stack is deliberately boring on the serving layer (FastAPI, HTMX, Tailwind, SQLite for now, Postgres on the roadmap) and deliberately interesting on the analysis layer (Claude and OpenAI for AI, full Jira Agile and Greenhopper APIs, live Kubernetes API calls, Prometheus metrics, MSSQL log ingestion). We chose this split because the parts that need to change fast (AI prompts, dashboards, analysis logic) should be cheap to iterate, and the parts that need to stay up (auth, persistence, RBAC) should be boring.

What Is Next

We are in the middle of taking Horizon from “internal tool that grew up well” to “multi-tenant SaaS that other engineering organisations can use”. The data model is already there. The remaining work is the kind of thing every product company has to do: per-org integrations for Jira and AI keys, Postgres migration, self-serve onboarding, and billing on top of the tier system that is already in place.

If you run a Kubernetes platform with more than a handful of tenants, run sprints in Jira, and have ever asked “is this release going to break prod”, Horizon is built for you. We are opening up early access to a small number of design partners over the next quarter.

Get in touch if you want to be one of them.