GitNotifier

The best Github PR notifications in your Slack DMs

Visit Website
July 29, 2026 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

Comment

July 20, 2026 How I got my first sale for GitNotifier (it wasn't the pricing page)

Hey, I'm Francois 👋. I build GitNotifier solo, and last week I got my first real subscription! I'm still super excited about it.

The interesting part: they were under the free-tier limit. The free plan already covered their whole team. Nothing was forcing them to pull out a credit card. They did it anyway.

Every bit of validation I had before this came from small startups sitting under the free limit. Nice to hear, costs them nothing. This one cost real money, from people who had a free option sitting right there. That is a very different signal 😅

TL;DR: a customer emailed me a question, I answered fast, that turned into a bug fix, then a feature, then another feature, all over five days. Then they subscribed to the paid plan they didn't need. Support was the product.

It started as a "how do I..." email

One morning I got an email from a team testing GitNotifier. They'd noticed review bot comments from GitHub were not showing up in Slack. Final approvals came through, individual bot comments did not. Fair question they asked me: how do I turn those on?

[For the context: GitNotifier is sending you relevant GitHub notifications directly in your slack DMs. By default, bot notifications are disabled to reduce the noise. let's continue]

I replied 16 minutes later that it was intentional: GitNotifier mutes bot comments by default so you don't get pinged by Vercel, Cloudflare, Claude, Cursor and friends all day. I told them where the setting lives and pitched two ideas I had been sitting on (a per-bot allow/deny list, and org-level defaults) to see if they cared.

They cared. And then they wrote back: the toggle was off, but the comments still weren't coming through.

So it was a bug 😅

The main use-case of Gitnotifier is to reduce Bot notifs compared to the default Github notifications. So it isn't the main flow that is battle-tested and heavily tested with e2e/smoke tests.

That should have worked out of the box, free plan or not. I told them straight: this looks like a regression I introduced recently, and I never noticed because I personally mute all bot comments so I never hit the code path. I said I'd look the next day.

Next day I fixed it. They started getting the Claude bot comments in Slack.

Then they found the next thing: the bot edits its own comment, and those edits weren't being pushed. Could I track updates too?

Turns out I could (but again, I never paid attention to receive bot updates before... Well they needed it). So I shipped it. Now edits and deletions show up as a fresh Slack message.

Then it turned into a feature

Once updates worked, they asked one more thing: the comments were truncated with a "..." in Slack. Could they see the full thing?

Good idea. A few hours later I had a preview feature that renders the full comment in Slack (which is annoyingly its own markdown flavour, not GitHub's, so it needed real work). Tested it against Cursor, Vercel, Cloudflare and Bito[.]ai bots and shipped it.

Their reply: "It works perfect. Thank you!"

They next day, they subscribed. Yearly!

What I actually learned

1. Support is not a cost center when you're small. It's the product.

I answered every email in under 15 minutes, and three of those emails turned into shipped code within a day. I wasn't doing "customer success." I was building the product live, in front of the one person who cared, using their exact workflow as the spec. You cannot buy feedback that tight. As a solo founder it is genuinely the highest-leverage thing I do all day.

The bonus: their bug reports made the product better for everyone. The bot-comment fix and the full-comment preview shipped to all users, not just them.

2. Willingness-to-pay when you don't have to is the only validation that counts.

Signups feel good. "This is cool, I'd use it" feels good. Neither means anything, because neither costs the person saying it a thing. Someone paying for a plan they don't need is the first data point I've had that survives contact with a wallet.

If your users are all on the free tier and happy, you don't know if you have a business yet. You know when someone upgrades without being cornered into it.

The uncomfortable takeaway

I got the sale because I was fast and I actually fixed things. That doesn't scale, and that's fine. At one paid customer, being unreasonably responsive is the moat. The day that stops being possible is a good problem to have later.

If you liked this story and/or if you're drowning in GitHub bot noise in Slack and want the human signal back, I'd genuinely love your feedback: GitNotifier.

And if you're pre-first-sale: go answer your users' emails faster than is reasonable. Mine turned into code, and the code turned into my first paying customer.

7 Comments

  1. 1

    Nice! I've actually been looking for something like this, but do you plan on adding some other notification options besides slack? To give you some context: I try to keep Slack closed during the day to reduce noise. (But because of that I also miss the GitHUb notification from the GitHub Slack app). I'd love to be able to add a tool in my app bar that would just give me a gentle nudge telling me there is a PR I need to review.

    1. 1

      I was thinking of maybe building something like this.

      In the meantime, if you use Mac, please check out Raycast and the awesome Github extension, it does something similar :) Let me know how it goes

  2. 1

    I like that the turning point wasn't the feature work itself—it was discovering what a customer was actually willing to pay for despite not needing to.

    I'll be interested to see whether future paying customers follow a similar path. If they consistently pay after experiencing your responsiveness rather than after comparing features, that pattern will probably reveal more about the business than the pricing page ever could.

    1. 1

      Yeah I am also curious about this!

      Let's see, now the real challenge is to find people interested by the product. I genuinely my product solves a real need (as I had this need myself as engineer). I just need to find a way to reach these persons 😅

      1. 1

        Appreciate the context.

        Finding the right people who have the problem is often the hardest part after building.

        Would be good to continue the conversation as you explore that.

        What's the best email to reach you on?

        1. 1

          Sure, but it seems like indiehackers does want me to post links yet. Send me an email to hello@<domain> (domain is from the link in the post)

          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.

About

After trying multiple similar products, they were either badly vibe-coded, too expensive or not doing what I wanted (I wanted only important Github notifications and reduce the notifs noise).