day log · platform team
Heimdall
One page showing where every ticket and every service actually is.
Built and run it solo · Loweconex, a UK IoT platform business · 2025 → ongoing
Before standup, before email, the platform team opens the same page. It answers one question across 20 services and four environments: where is my ticket right now? More than 20 engineers use it every morning, and standup runs off it.
The environments view, in your browser
Crashlooping in qa (1/2 pods). The promotion gate is holding it back.
Five tabs, one question
Across 20 services and a dev → QA → preprod → prod pipeline, the state of any given ticket is spread across five systems. Bitbucket holds the commit and the PR, JIRA holds the ticket, and Kubernetes holds the pods that are running. In between sits the GitOps repo, which holds the desired state: the commit each environment is supposed to be on, which isn't always the one it's on.
Heimdall started as a small Python service that pushed the four DORA metrics (deploy frequency, lead time, change failure rate, time to restore) into Prometheus. The original collector was correct and nobody ever opened it. Building the UI is what turned it into something more than 20 engineers now use every day.
A short tour
Six pages; these three do most of the work.
There's also a PR triage view sorted by what unblocks shipping rather than what's most recent, and an activity feed of every deploy, sync and promotion, which is the first place anyone looks during an incident.
How it's built
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. Pages stay fast under load because the work happens elsewhere.
Heimdall · system overview
Tap or click any box for a one-line explanation.
sources
background work
stores
web
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.
What it reads, and what it refuses to believe
Heimdall's real job is reconciling five systems that each hold one piece of the answer. The design decision that mattered was which one to believe when they disagree.
The ticket, so the whole thing can be asked in a human's terms: where is PLAT-2044 right now?
PRs, merges and review state. This is where the bottleneck usually is, and it's the part people are least willing to guess at.
Sync status and the revision each environment is meant to be running.
Not its health verdict. ArgoCD will report a service healthy while its new pods crashloop behind it, so Heimdall checks the pods directly instead.
Pod state, read directly. This is what health means here, and it's why Heimdall can disagree with ArgoCD.
Post-deploy verification. Heimdall records whether the tests came back green after the new pods came up.
Reading five systems means five things that can be down, so Heimdall has to be diagnosable by someone who has never seen its code. The README opens with "is it healthy?" and answers it in one curl: collection age, pool usage, every circuit breaker.
What changed
The team stopped pasting kubectl output into Teams to ask whether a deploy had worked. Standup got shorter. Release management started using the same view as the engineers, so fewer tickets fell down the gap between them.