Incident Triage Alert

• Your error-monitoring tool (Sentry, or anything sending the same webhook format) fires a webhook the moment an issue is created, resolved, or changes status
• The bot reads the real details out of that webhook — project, severity, status, title, and link — with no manual copy-pasting
• AI turns that into a short, readable summary instead of a wall of raw fields
• The alert goes out instantly to every contact tagged as an admin in your bot — no chat ID or user ID hardcoded anywhere
• From there, your team can extend the flow with acknowledgement or escalation steps whenever you're ready

• In your monitoring tool (Sentry or equivalent), add a webhook integration pointed at your bot's webhook URL, ending in /webhooks/sentry/issues.
• On the Contacts page, tag your internal responders with admin — or change the adminAudienceTag variable if your team already uses a different tag.
• Send a test issue through the webhook and confirm your tagged admins receive the summary with project, severity and a link to the issue.
• Review the AI prompt so the summary matches how your team actually talks about severity and urgency, then adjust it if needed.

Good to know

• Built for the standard Sentry issue-webhook shape, so anything else that sends webhooks the same way (an action plus issue details) works too.
• Delivery is audience-based, not address-based: the bot looks at who's tagged admin (or whatever tag you choose) at the moment the alert fires, so nobody has to touch chat IDs.
• It alerts on every issue event your monitoring tool sends by default. If you only want alerts for certain events — say, new and regressed issues, not every status change — that's a filter to set on the monitoring side, in your alert rules.
• This version notifies and summarizes; it doesn't take any remediation action on its own. Acknowledgement, escalation, or auto-creating a ticket are natural next steps to add once the basics are working.

Common questions

• Should alerts go to contacts tagged admin, or a different tag your team already uses?
• Which kinds of issue events should actually trigger an alert — every one, or just new and regressed issues?
• Should this stay notify-only for now, or should a later version also open a ticket in GitHub or Jira automatically?

Keep in mind

• Keep this for your internal team only — never point it at a customer-facing audience, since incident alerts can include sensitive details.
• Don't treat an alert as confirmation something is fixed — it only reflects what your monitoring tool reported at that moment.
• Be mindful of what your monitoring payload includes: if it can carry secrets, tokens or stack traces you don't want circulating, the admin-only audience is your safeguard, so don't broaden who receives these alerts.