Heimdall

Across 17 services and a dev → QA → preprod → prod pipeline, the state of any given ticket is scattered. The commit's in Bitbucket. The desired state is in the GitOps repo. The pods are in Kubernetes. The tests are in Sentry. The ticket is in JIRA.

Heimdall started life as a small Python service that exposed DORA counters to Prometheus — handy for leadership, but it didn't help anyone shipping a feature on a Tuesday afternoon. So I built a UI on top, and kept building until it was the first tab people opened.

It's now used daily by the engineering team and runs the morning stand-up.

Six pages. Each one answers a question someone's about to ask in Slack.

dashboard

The pipeline at the top — how many tickets are at each stage, and how long each handover takes. Underneath, the last 24 hours of deploys and a 30-day rollup. DORA metrics in a glance, no Grafana detour required.

tickets

Every open ticket grouped by environment, stuck ones first. The "PRs ready" card surfaces the PRs with approval and green CI just waiting on a merge — usually two or three a day.

environments

Per-environment cards on top. The matrix below is one row per service, one column per environment — a green cell means the env is on the latest commit, red means it's drifted. This view replaced about five recurring Slack threads.

environment detail

Drilldown for one environment. "Ready to promote" lists the services where the next env can safely take the new commit. Below that, per-service health, error rate, p95, and pod resource pressure.

pull requests

The same PRs Bitbucket has, but sorted by what unblocks shipping rather than what's most recent. Ready first, then CI failing, then needs review, then stale.

activity

A chronological feed of every deploy, sync, and promotion. The first place you look during an incident, and a useful way to open standup.

One Python service. A background job pulls from the upstream sources every ten minutes and writes everything down — once into a database, once into an in-memory cache the web app reads from. The web app itself does no fetching, no joins, no slow work. That's the whole trick. Pages stay fast under load because the work happens elsewhere.

The data model thinks of a deployment as a lifecycle, not an event: PR merged → tag updated → pods healthy → tests pass. A database view joins them all into one queryable thing, which is what powers the pages above.

The numbers I care about most aren't in the table. The team stopped pasting kubectl output into Slack to ask if a deploy worked. Standup got shorter. Release management started using the same view as the engineers, which meant fewer dropped tickets at the seams. I'm still finding things to improve.