Inspiration
The worst part of an incident isn't the bug. It's the twenty minutes before a human is even awake to look at it. The pager goes off, someone fumbles for a laptop, finds the dashboard, reads the logs, forms a theory, ships a fix, and only then starts the clock on recovery. Every one of those minutes is downtime, and most of them are spent just getting a person into the loop.
"Life After Code" is exactly where this lives. The code shipped fine. It's the 2am regression, the dependency that went bad, the divide-by-zero that only shows up under load, that actually costs you. We wanted to see how much of the on-call response an agent could own end to end, with no human in the critical path, and still leave behind a record a human would trust in the morning.
Lifeline is our answer. It's hands-off on purpose. When something breaks, it doesn't wait to be asked.
What it does
Lifeline is a live incident-response console with a GitLab Duo agent running the response behind it.
The automation: the Incident Commander
A health check starts failing, or an error rate spikes. That's the trigger. An alert lands as an issue, and the Lifeline Incident Commander flow takes the whole thing from there, with nobody driving:
- Detect. It reads the alert and the failing signal and confirms the incident is real.
- Diagnose. It opens the code and the pipeline, finds the root cause, and says what broke in plain language.
- Patch. It writes the fix and commits it.
- Recover. It redeploys and watches the health check come back green.
- Learn. It writes a post-mortem with the measured time to recovery and posts it back on the incident timeline.
Every step lands as its own INC-n commit, so the whole response reads back as a clean, timestamped trail. It runs on Anthropic Claude through Google Vertex AI. This is the hands-off path: the agent does all five steps itself and leaves the post-mortem for a human to read, not to approve.
The application: the incident console
The thing Lifeline watches is a real service with a console you can open and use.
The dashboard leads with a single status line that tells you whether everything's healthy, degraded, or in a major disruption. Under it sit the numbers that actually matter on call: open and resolved incidents, mean time to recovery, and the failed-probe rate, with a recovery-time chart and an hourly failed-probe chart drawn inline. There's a service-health panel with live heartbeat traces, the open incidents, and a feed of recent activity.
Open any service and you get its uptime, median latency, a latency chart, a failed-probe chart, and that service's incident history. Open any incident and you walk its response on a Detect, Diagnose, Patch, Recover, Learn rail, with the full timeline, the findings, and a post-mortem that writes itself once the incident resolves and can be copied or downloaded as markdown.
And then there's the drill room. One button breaks a target on purpose, and you watch Lifeline catch it and heal it, live, with the heartbeat trace and the response rail updating as it goes. It's the demo you can run yourself in thirty seconds.
How it works (architecture)
The app is a Flask backend with a React and Vite console on top, in a "chart-paper" design built from a small component set with inline-SVG charts. The backend tracks services, heartbeats, probes, incidents, and post-mortems, and exposes the dashboard, service detail, and incident detail the console reads.
The automation is a custom GitLab Duo flow, the Lifeline Incident Commander, with its own on-call agent, both published to the GitLab AI Catalog through a catalog-sync CI component. The flow is wired to fire on a failing signal rather than a mention, which is what makes it genuinely hands-off. It runs on Claude via Vertex AI, and the service is containerised with Cloud Build and served on Cloud Run.
How we built it
Lifeline started from our own monitoring codebase and we rebuilt it into an incident console with a real response loop. We modelled an incident as five phases so the agent's work and the UI's story line up exactly, then wired a demo where a one-line change on feature/inline-error-rate sends /health into a cold-start divide-by-zero. The alert fires, the flow runs detect through learn, and the pipeline comes back green with a post-mortem attached. The drill room is the same loop on a button, so anyone can trigger it without waiting for a real outage.
Challenges we ran into
Making the response genuinely hands-off meant the trigger had to be the failing signal itself, not a human mention, so the flow had to key off pipeline and health state. Lining the five phases up across the agent and the console took a couple of passes, because a half-filled rail reads worse than no rail at all. We also had to make sub-ten-second recoveries legible: a drill that heals in half a second was rounding to "1s" and reading like nothing happened, so recovery times now show a decimal when they're short.
Accomplishments we're proud of
A full incident response that a human never has to touch, start to finish, that still leaves a readable post-mortem and a measured MTTR behind. And a console good enough to run on-call from: live heartbeats, real charts, and a drill you can fire yourself to watch the whole thing happen.
What we learned
Hands-off only earns trust if the aftermath is legible. The post-mortem and the phase rail turned out to matter as much as the fix, because they're what a human reads to decide whether the agent did the right thing. We also learned how much the trigger shapes the product: keying off the failing signal instead of a mention is the difference between an assistant you summon and an on-call engineer that's already working.
What's next
Correlating related alerts into a single incident instead of several, learning each service's normal baseline so detection gets sharper, and a "confidence to act" threshold so a low-confidence diagnosis escalates to a human instead of shipping on its own.
Log in or sign up for Devpost to join the conversation.