I've started building a bug watcher for my apps. Twice a week it collects errors from production, decides which ones matter, and starts a fix without me asking.
Right now I'm the monitoring system. A user hits a problem, or I happen to open an error log, and only then do I find out something has been broken for days. That's a bad way to run anything, and it gets worse with every app I add.
What it does
The plan is simple:
- Twice a week, it pulls the errors my live apps have been throwing.
- It sorts the noise from the real problems. Most errors are one-off junk, and a few are things people actually run into.
- For the ones that matter, it starts working on a fix and hands me the result to review.
The last part is the important one. I don't want a report I have to read and then act on. A report is just another thing to remember. I want to come back to a proposed fix and say yes or no.
Where it is
It's early. I built it mostly out of pieces I already had: some error collection, and a tool that can start a fix for a reported problem. The new work is connecting them and teaching it to judge what's worth fixing.
The first run did flag something real, which was a nice sign. It's too soon to say how often it'll be right, though. My worry is that it picks the wrong things, or fixes the symptom and not the cause. So for now I'm the one approving everything.
What's next
I'll watch a few weeks of runs and see how many of its picks I agree with. If it's good, I'll loosen the leash a little. If it keeps chasing noise, I'll tighten how it decides what matters.
Either way, I'd like to find out about bugs from my own tooling and not from someone else.