1
0 Comments

How I built a cheap AI agent SRE for my product

I run GitNotifier alone. There is no on-call rotation, no ops team, no pager. But production still needs someone to look at it, and at 4am that someone is not going to be me.

So I gave the job to a scheduled AI agent. Once a day it reads my production logs, tells me what happened, and opens a draft PR when it spots something easy to fix. I wake up to a summary instead of a surprise.

The problem with being the only engineer

When you are the only person on a project, nobody reads the logs until a user complains. Loud outages you notice. The quiet stuff you do not: a handler throwing a caught error a few hundred times a day, a log line printing a full object on every request, latency creeping up one week at a time.

None of that pages you. It just sits there, and you find it weeks later while debugging something else.

Even with using tools like Posthog, Sentry and Grafana Cloud, sometimes an error logs but do not throw which is easy to miss.

The Claude routine

I set up a scheduled Claude agent (a "routine") that runs once a day. It connects to my log stack (Grafana Cloud <3), queries the production logs for my API, and writes up what it finds. My backend runs on Cloudflare Workers and ships logs into Grafana Cloud, so the agent queries there, but the shape of this works with any log backend an agent can reach.

The prompt is intentionally boring. Roughly:

"Scan the production logs for my API service over the last 24 hours.
Give me:

  • A summary of any error or warn logs. If there is an easy fix, open a draft PR and send me the link.

  • A summary of what the app did: how many notifications sent, usage patterns, anything else I would find interesting.

  • Any logs that are too verbose and should be trimmed.

If a fix makes sense, make the change on a branch and open a draft PR.

Post a summary to Discord. If nothing is worth mentioning, stay quiet."

That last line does a lot of work. No alert fatigue means I actually read the ones that arrive.

What a typical run does

  • Summarises the error and warn logs, grouped by what actually caused them (really useful, I can just check a message on my phone rather than opening the observability platform UI to assess the gravity of the errors spotted)

- Reports app activity: notifications sent, top users, and patterns worth a second look.

- Flags log lines that are too verbose and quietly inflating my log bill.

- Opens a draft PR for the easy fixes and links it in the summary.

- Posts the whole thing to Discord, or sends nothing when there is nothing to say.

The draft PR part is my favorite. A typical trim-the-verbose-logging change is a one line diff. Having it waiting for me as a reviewable PR, instead of a "TODO: clean up logging" I will never do, is the difference between it happening and not.

Don't be blinded by the Agent

Something really important to call out, it doesn't mean a bunch of errors happen in production and this catches them.

Before production, there are 700+ unit and integration tests, e2e smoke tests, linting, PR reviews, local and preview environments, etc. It's not up to luck.

The Agent prompt is doing what I want it to be: an AI SRE agent fixing the unexpected.

Also, It also does not replace real alerting. If the API falls over at noon, this routine is not going to tell me until 4am. It catches slow creep, not fires. I still want proper alerts for the loud failures. This is the thing that watches the quiet ones.

Six months in, the honest result is that it works beautifully.

I build GitNotifier, which sends clear GitHub notifications to Slack. If you want to see it: https://gitnotifier.com

posted toAvatar for product GitNotifier
GitNotifier