// observability [Agent spend monitoring]
Burnwatch Observability
Observe-only SDK ingest, explainable rules, and wallet-risk alerts
Observability for autonomous payments
Autonomous agents can make hundreds of payments a minute. Burnwatch treats that wallet activity like production telemetry: mirror the payment metadata, scope it to an org and agent, learn normal behavior, and raise explainable alerts when spend changes shape. The important architecture choice is what Burnwatch refuses to do — it never holds keys, never approves payments, and never becomes a dependency in the payment path.
- Python SDK
- Next.js 15
- TypeScript
- Postgres
- Stripe
- Vercel
- Slack webhooks
// architecture
Agent payment ──► SDK record() ──► ingest API ──► rules + baselines ──► email / Slack / webhook alert
// how it's built
Agents call bw.record() after each payment with amount, recipient, rail, timestamp, and metadata. The SDK mirrors telemetry only; payment authorization stays with the agent and its wallet provider.
Burnwatch is deliberately outside the transaction path. If ingest is slow or unavailable, the agent can keep paying. The product should reveal risk without becoming a new outage mode.
Each agent posts with an ingest token scoped to an organization. The backend associates events to agent, org, and rail before any rule evaluation so dashboards and audit logs stay tenant-isolated.
New agents enter a learning period before anomaly rules fire. Burnwatch builds normal ranges for recipient frequency, spend velocity, rail mix, and active hours so first-run traffic does not become noise.
Rules cover velocity spikes, drain bursts, unknown payees, new rails, off-hours spend, and pattern changes. The system favors readable thresholds and evidence JSON over black-box anomaly scores.
Alerts can route to email, Slack, Discord, Teams, or webhook endpoints depending on plan. Every alert includes why it fired, the triggering event window, and enough context for a human to decide whether to pause an agent.
Next.js powers fleet views, per-agent spend charts, alert management, settings, and Stripe-backed plans. The dashboard explains what Burnwatch saw; it does not hide the rule that made the call.
// highlights
Burnwatch mirrors metadata only. It cannot sign, approve, block, or reroute a payment, which keeps blast radius low.
Each event carries amount, rail, recipient, agent, timestamp, and evidence metadata so spend can be queried like production observability data.
Alerts include the exact rule, threshold, and event window that fired — useful for operators, support, and audit trails.
Agents learn normal behavior before detections fire, reducing alert fatigue during setup and first traffic.
Fleet view, per-agent charts, alert state, and audit history are scoped by organization and ingest token.
Built around autonomous x402, stablecoin, and custom-rail payments where a human may not be watching every transaction.
// components
Small Python package plus token-scoped API endpoint for recording payment metadata after the agent pays.
Detection layer that combines warm-up ranges with transparent rules and stores human-readable evidence for every alert.
Dashboard, notifications, and webhook delivery that help teams investigate, suppress, or escalate risky payment behavior.
// related work