Automate Daily Production Error Triage

Zero pulls unresolved errors from Sentry and Axiom every morning, deduplicates them, opens GitHub issues with full stack traces, and assigns the right engineer automatically.

Zero connects:

What Zero delivers

Automate Daily Production Error Triage — sample output from Zero — screenshot 1

What the problem is

Every morning, someone has to open Sentry, scroll through unresolved errors, figure out which ones are new, which are duplicates, which are actually serious, and decide who should own each one. That is 20 to 30 minutes of focused engineering time before any real work starts. Zero runs at 8:45 AM, checks Sentry and Axiom, deduplicates across both, picks the errors that matter, opens GitHub issues with the full stack trace already attached, and assigns each one before anyone opens their laptop.

How Zero fixes it

Step 1: Connect your tools

Sentry

Required

Zero queries Sentry for unresolved errors and reads stack traces and event counts.

Connect

GitHub

Required

Zero files structured GitHub issues with full error details and assigns to code owners.

Connect

Axiom

Optional

Zero queries Axiom for error logs to cross-reference and deduplicate against Sentry findings. Optional but recommended.

Connect

Step 2: Ask Zero

@Zero every weekday at 8:45am, pull unresolved errors from Sentry and Axiom for the last 24 hours. Deduplicate across sources. For anything with 5+ occurrences, open a GitHub issue in vm0-ai/vm0 with the full stack trace and assign to the relevant code owner.

try it

Zero pulls errors from Sentry and Axiom

Zero queries both sources for unresolved errors within the specified time window. It applies your occurrence threshold to filter out noise and focus on errors that are actually happening at scale.

Errors deduplicated across sources

The same error often shows up in both Sentry and Axiom with different formatting. Zero identifies duplicates and merges them into a single record with data from both sources.

GitHub issues filed and assigned

For each unique, qualifying error, Zero opens a structured GitHub issue with the full stack trace, occurrence count, first and last seen timestamps, and assigns it to the engineer most likely to own that area of the code.

Step 3: Take it further

Adjust the threshold

Change the occurrence filter to reduce noise or catch more issues

@Zero update the daily triage schedule to only file issues for errors with 10+ occurrences. Anything below that, just post a summary to #dev.

try it

Add to the morning brief

Combine with the product health briefing use case

@Zero include today's error triage output in the 9am product health brief you post to #standup.

try it

Post-deploy safety check

Run triage immediately after a production deploy

@Zero whenever a PR merges to main in vm0-ai/vm0, wait 15 minutes and then run a Sentry error check for new errors.

try it

Tips for better results

●Set an occurrence threshold to keep the issue count manageable. 5+ is a good starting point; adjust based on your volume.

●Use Sentry's project tags or environments to narrow Zero's query to production only, not staging.

●Chain this with the product health briefing: run triage at 8:45, include output in the 9:00 brief so the team sees everything in one place.