fault line

Faultline: Gemini 3.1 Pro agent reads Cloud telemetry, ranks GitLab commits by symptom→change fit (not recency)names the bugstages a DRAFT rollback MR via MCP You click Approve. It never merges itself

Comment

Inspiration

Every team's incident playbook starts the same way: which service is actually broken, which commit caused it, where's the safe rollback. Senior SREs do that triage in their head in under a minute. Junior engineers and new hires need ten.

That ten-minute gap is mechanical — read dashboards, scroll commits, match a symptom to a diff — exactly the work an agent should do.

The interesting question isn't "can an LLM read GitLab and Cloud Monitoring." It can. The question is "can it pick the right commit." Most auto-RCA tools rank suspect commits by recency or by fuzzy embedding similarity — and produce a noisy list. Faultline started from the observation that human SREs don't rank by recency. They rank by causal fit between the symptom class and the change class:

  • Latency creep → a query-loop change, not a typo fix.
  • 5xx spike → a new dependency or auth change, not a docs PR.
  • OOM → a pool / allocation change.

We wanted to bake that reasoning step into a Gemini 3 agent.

What it does

Faultline is an autonomous Gemini agent that runs an eight-step incident investigation policy end-to-end, gated by a single human Approve click.

  1. Reads Google Cloud telemetry — Cloud Monitoring + Cloud Logging — to identify the alerting service and symptom class.
  2. Walks the service dependency graph to find the real source of the cascade, not the first red alert.
  3. Pulls recent commits + merge requests on the suspect service via the GitLab MCP server.
  4. Reads the suspect diffs through GitLab MCP.
  5. Matches symptom class to change class — the key reasoning step. Ranks candidate commits by causal fit, not by recency.
  6. Converges on one offending commit with explicit confidence and a stated causal chain (commit → mechanism → symptom).
  7. Drafts a blameless postmortem, opens a GitLab issue, stages a DRAFT rollback merge request — all through the GitLab MCP server.
  8. Stops. Surfaces everything to the human. Awaits explicit Approve.

When the human clicks Approve, the FastAPI server (not the agent) strips the Draft: prefix and merges the MR via GitLab REST. The merge fires the victim's GitLab CI and the service recovers.

The agent literally cannot merge: the merge tool is not in the registered toolset. Even if the model hallucinated a merge tool call, the ADK MCP client would 404. The Approve click is the only path to a merge — enforced at the tool-schema level, not by a prompt rule.

Built With

Share this project:

Updates