error monitoring agent

Abstract

Intelligent error monitoring agent that uses Airweave to find context from your code, tickets, and Slack. Clusters similar errors, enriches with relevant context, and creates actionable alerts.

The Problem

Error monitoring tools generate raw alerts but leave the hard part to engineers: figuring out what code caused the error, whether it's a known issue, and how severe it is. This agent addresses that gap by clustering similar errors and enriching them with context from your codebase, ticketing system, and Slack history before deciding what to alert on.

What This Does

The backend (backend/main.py) runs a pipeline that ingests errors from Sentry, Azure Log Analytics, or a custom source, clusters them by root cause (backend/pipeline/clustering.py), searches for relevant code, tickets, and Slack threads via Airweave (backend/clients/airweaveclient.py), and classifies severity with suppression logic (backend/pipeline/analysis.py). The frontend (frontend/src/App.tsx) provides an interactive visualization of the pipeline using sample data.

The system reduces alert noise: 20 raw errors become 4 actionable clusters. It also integrates with Linear (backend/clients/linearclient.py) and Slack (backend/clients/slackclient.py) to preview what alerts would look like without creating real tickets or messages.

How To Use It

Setup: The backend uses Python with dependencies in backend/requirements.txt. The frontend uses npm with frontend/package.json.

Configuration: Copy .env.example to .env and set DATASOURCE (sentry, azure, or default sample). Optional: add OPENAIAPIKEY or ANTHROPICAPIKEY for smarter clustering. For Sentry: SENTRYAUTHTOKEN, SENTRYORGSLUG. For Azure: AZURETENANTID, AZURECLIENTID, AZURECLIENTSECRET, AZURELOGANALYTICSWORKSPACEID.

Running it (from README): Start backend cd backend python -m venv venv && source venv/bin/activate pip install -r requirements.txt uvicorn main:app --reload --port 8000

Start frontend (new terminal)

cd frontend npm install && npm run dev

Open http://localhost:3000 and click Run Demo. The demo uses sample data and mock search results—no real tickets or messages are created.

Real-World Use

For a team running Sentry, this replaces the manual triage loop. Configure DATA_SOURCE=sentry, point the agent at your project, and it groups errors by root cause, pulls the relevant GitHub code and past Linear tickets, and sends a single Slack alert per cluster instead of one per error. Custom sources are straightforward: implement backend/sources/base.py and return a list of RawError objects.

Code Health & Issues

Med - No tests: No test files exist anywhere in the repo. The clustering and analysis logic in backend/pipeline/ is untested, which is risky for a tool that decides alert severity. Med - No CI/CD: No .github/ directory or CI config. No automated build or test gate. Med - No LICENSE: Usage and redistribution rights are undefined. Low - Hardcoded sample data: backend/samples/errors.py is the default source, which is fine for demos but means the production path (sentry/azure) is exercised less. Low - Tight coupling: backend/pipeline/actions.py handles both analysis and alert creation; separating these would improve testability.

The Bottom Line

This is a well-structured demo of an intelligent error monitoring pipeline, with clean separation between sources, pipeline stages, and clients. It's useful as a reference implementation or a starting point for a production system, but the lack of tests and CI means it needs hardening before deployment. Best suited for teams already using Sentry or Azure Log Analytics who want to reduce alert fatigue without building this from scratch.