# Bug Ticket Agent — AI-Powered Sentry Triage into Notion

Steven Nguyen — Sun, 29 Mar 2026 03:49:02 +0000

Bug Ticket Agent — AI-Powered Sentry Triage into Notion

This is a submission for the Notion MCP Challenge.

What I Built

Every time an error fires in production, someone on your team has to open Sentry, read through the stack trace, decide how urgent it is, and manually write a ticket. That happens at 2am. People skip steps. Duplicates pile up.

Bug Ticket Agent automates the entire triage workflow. It listens for Sentry webhooks, runs a Claude AI agent to analyze each error, and writes a structured, prioritized ticket directly into a Notion database — including deduplication, AI-generated summaries, and suggested fixes.

Key Capabilities

Automatic intake — receives Sentry webhook events and queues them for processing
Intelligent deduplication — searches Notion before creating anything; updates existing tickets instead of duplicating
AI priority assignment — Claude assigns P0–P3 based on environment, user impact, and frequency
Structured tickets — every ticket gets an error type, stack trace, affected users, AI summary, and a concrete fix suggestion
Escalation alerts — P0/P1 production errors are flagged immediately for PagerDuty/Slack wiring
Queue-based processing — serialized job queue prevents race conditions when Sentry fires bursts of events

Demo

[Terminal A — server running]
🐛 bug-ticket-agent running on http://localhost:3000

[Terminal B — send a P0]
$ npm run demo -- --scenario p0

→ Webhook received: "TypeError: Cannot read properties of undefined (reading 'charge')"
→ Triage started...
→ Searching Notion for duplicates... none found
→ Assigning priority: P0 (payment service, 247 affected users, production)
→ Writing summary and suggested fix...
→ Creating Notion ticket... ✓ page_id: abc123

⚠️  ESCALATION ALERT: P0 detected in production — notify on-call immediately

[Notion database — ticket appears]
Title:    TypeError: Cannot read properties of undefined (reading 'charge')
Priority: P0
Env:      production
Users:    247
Summary:  "Payment processing failed due to a null reference on the charge object..."
Fix:      "Add a null check for stripe.charge in src/payments/processor.ts:88"

[Send the same error again]
$ npm run demo -- --scenario duplicate

→ Searching Notion for duplicates... found existing ticket (page_id: abc123)
→ Updating frequency: 12 → 18 occurrences, last seen: now
→ Done. No duplicate created.

Show Us the Code

GitHub: bug-ticket-agent

Sentry Webhook
     │
     ▼
Express Server  ──→  Job Queue (serialized)
                          │
                          ▼
                   Claude Triage Agent
                    ├── Search Notion (duplicate check)
                    ├── Assign P0–P3 priority
                    ├── Write summary + fix suggestion
                    └── Create or Update Notion page
                              │
                              ▼
                       Notion Database
                     (Bug Tracker, live)

Tech stack: TypeScript · Express · Claude claude-sonnet-4-6 · Notion MCP Server · Zod

How I Used Notion MCP

1. Claude Discovers Tools at Runtime

Instead of hardcoding Notion API calls, I spin up the official Notion MCP server over stdio and let Claude fetch the available tools on startup. Claude then decides which tools to call and in what order — search-database, create-page, update-page — based on what it finds.

This means zero Notion API wrapper code on my end. If Notion adds new MCP tools, the agent gets them for free.

2. Deduplication via MCP Search

The first thing Claude does in every triage loop is call the Notion search tool with the error title. If it finds a matching ticket, it updates frequency and last-seen instead of creating a new one. This logic lives entirely in the agent prompt — not in hand-written code:

1. Search the database for an existing ticket matching this error title.
2. If duplicate found: update frequency and last seen. Report the page ID.
3. If no duplicate: assign priority, write summary and fix, create a new page.

3. Structured Tickets via MCP Create

When Claude creates a ticket, it maps the error data to Notion's property schema — priority as a select, environment as a multi-select, stack trace as a code block, summary and fix as rich text. The Notion MCP server handles all the property formatting; Claude just fills in the values.

4. The Priority Rubric

Claude doesn't guess — it applies a deterministic rubric from the system prompt:

Priority	Criteria
P0	Production down, data loss, auth/payment broken, or >100 affected users
P1	Major feature broken, >10 affected users, recurring in production
P2	Minor degradation, <10 users, workaround exists, or staging
P3	Cosmetic, single user, dev environment, very low frequency

What This Unlocks

Before this: an engineer gets paged, opens Sentry, reads the error, manually creates a Notion ticket, assigns a priority based on gut feel, and hopes they didn't miss a duplicate.

After this: the ticket is already in Notion by the time the engineer opens Slack. It has a priority, a summary, a suggested fix, and no duplicate. The engineer can go straight to fixing instead of triaging.

The Notion MCP server made this possible without building a custom Notion integration. Claude handled all the tool orchestration — I just described what I wanted in the system prompt.

DEV Community: Steven Nguyen