Hey folks, been experimenting with SuperAGI for a few weeks now to automate some SRE toil. I set up an agent with a straightforward goal: monitor our aggregated application error logs (via Loki) and automatically create Jira tickets for any new, unique errors that pop up.
The initial setup was surprisingly smooth. The agent can definitely *do* the job—it parses logs, deduplicates somewhat, and creates well-formatted tickets with stack traces. The problem is the sheer volume. It's creating a ticket for almost every unique error trace, even for transient issues that resolve in seconds or are already covered by existing alerts. My Jira project is being flooded, and my team is starting to ignore the notifications.
Here's what I'm seeing:
* **Lack of intelligent throttling:** It doesn't seem to correlate errors that are likely from the same root cause but have slightly different messages.
* **Noisy by default:** There's no built-in sense of "error budget" or severity filtering that aligns with our PagerDuty alerts. A minor, one-off client-side error gets the same ticket priority as a recurring backend 500.
* **Context is shallow:** The ticket has the error, but the agent isn't pulling in related metrics (like a Grafana dashboard snapshot) or recent deployment context to help triage.
I love the concept, but right now it's adding more noise than signal. Has anyone else built a similar monitoring/alerting agent and found a way to make it smarter?
I'm thinking I might need to:
- Pre-filter logs more aggressively before they reach the agent.
- Build a custom tool for the agent that checks error frequency over a window.
- Maybe use the agent to *update* an existing ticket instead of always creating a new one.
Would love to hear how you're tuning these workflows or if you've found a good pattern for making log-based agents actually useful for on-call.
—Chris
K8s enthusiast
Exactly the pain point I hit last year. Your agent is stuck at the "detection" layer without any of the "signal processing" we'd bake into a normal alert rule.
That shallow context is killer. My quick fix was to add a filter step before the agent: only pass logs where the same error pattern occurred N times in M minutes, or where a specific high-severity keyword (like "panic" or "fatal") appeared. You can do that with a simple Loki recording rule or even a sidecar container.
Also, tie it to your existing alertmanager if you can. If an error is already triggering a PagerDuty alert, maybe that's enough and you don't need a Jira ticket too. Otherwise you're just creating notification fatigue.
K8s enthusiast
Ah, the classic "automation creates more work than it saves" phase. We've all been there. Your agent is basically a very enthusiastic intern on their first day, flagging every single irregularity it sees.
That shallow context point is key. A stack trace alone, without the surrounding system state, is just a complaint without the "why." I added a step to my own bot where it pulls the error rate for that service from Prometheus for the 10 minutes before the log. If the rate is flat and low, it just logs the incident to a "transient noise" dashboard instead of Jira. Cuts down probably 60% of the chatter.
Have you thought about feeding it the resolution of past, similar tickets? If an error with the same signature had a ticket closed as "non-issue" or "transient load" last week, maybe it should just add a comment to the old one instead of spawning a new ticket. That's trickier to wire up, though.
it worked on my machine