ÖÖTÖÖ Internal Tool

Customers notice the bugs monitoring can't see. We turn their reports into the fix and get it to the right team.

Comment

Inspiration

We came in planning to build something for Wise customers and spent four hours killing our own ideas. What changed our direction was talking to Wise engineers. Three of them, separately, pointed at the same thing: the big incidents are already handled. Dashboards go red, the on-call engineer gets a call, and teams react. What gets missed are the small bugs that throw no error at all. One engineer's example was card pictures that flickered for ages until someone fixed them with Claude Code. No monitoring could see it. In his words, "it's all about the nitpicks… edge cases that are taking time or never being fixed."

Only customers notice those bugs, and they tell support. Then support has to work out by hand that several tickets are the same problem, find which of thousands of services owns that page, guess which recent change broke it, and chase the right person in Slack. An on-call engineer told us that customer reports with no alert behind them come "fairly often", and that the first thing he would automate is digging through recent releases across repositories by hand.

What it does

The tool watches the support channel in Slack. When several customers report the same thing, it:

  1. Groups the reports into one problem and posts a th
  2. Checks Prometheus, and usually finds nothing, which is the point.
  3. Reads the recent changes and names the commit it suspects.
  4. Finds the service and the team that owns it.
  5. Investigates the code and decides the severity.

For a low severity bug (the card picture flickers), it writes a fix, runs the tests, opens a pull request and hands the owning team a summary with an Approve fix button. One press mbug is gone.

For a high severity bug (a transfer amount shown as "2,40.00"), it touches no code. The team gets the origin, the responsible commit, what is wrong in the code and what to do next.

Either way, support gets one approved sentence to send customers.

Measured on our counted runs: about 45 to 50 seconds approve to the merged pull request.

How we built it

  • The tool is TypeScript on Node. It listens to Slack, reads GitHub, and queries Prometheus over its HTTP API. Grouping, investigation and the fix run on Claude Code in headl
  • A stand-in bank app ("Demo Bank") has a card page and a transfers page, with two real bugs planted in its git history. A watcher redeploys it when a pull request merges, so the fix i
  • Real monitoring. Prometheus 3.15.1 scrapes the app, and Grafana shows the same data on the screen Wise engineers know.
  • A process screen shows each step as it happens:
  • A helpdesk stand-in forwards customer messages to Slack with personal details removed.

Five of us split the work through GitHub issues, each person on their own branch with their own coding agent. We wrote 363 tests and ran the whole flow through to a pull request more than 40 times overnight before calling the build proven.

$$ \text{saved per bug} \approx \underbrace{400}_{\text{customers}} \times 12\ \text{min} + \text{support time} + \text{developer time} \approx 85\ \text{hours} $$

That figure is our estimate. Every input in it is a g

Challenges

  • Proving it is new. Turning a bug report into a that. What we did not find anywhere is starting from several customer reports with no alert behind them and ending with the suspect commit, the owner and a decision on whether to fix at all.
  • Knowing when not to fix. An automatic fix on a mattered more than the fix itself.
  • Making a live demo reliable. Real Slack, real GitHub and a real model all add timing noise. We counted runs, measured every step, and wrote a fallback for each thing that can fail on
  • Windows. The stage laptop runs Windows, and small things like which tar unpacks Grafana broke setups that worked elsewhere.

What we learned

The best problem came from asking engineers what wastes their time, not from guessing what customers want. Our first ideas died on simple questions we asked ourselves: who exactly, howcommit, you decide" earns more trust than one that always acts.

AI disclosure

Built with Claude Code and Codex. The tool itself uses Claude Code to investigate and write fixes.

Built With

Share this project:

Updates

Submission history