Did the last Heroku deploy cause this Sentry error?

When a new Sentry error appears, we check your latest Heroku deploy, alert your team in Slack with the likely cause, and open a GitHub triage ticket.

Agentic Task
HerokuSentrySlack BotGitHubEngineeringNotifications & AlertsResearch & Monitoring
PromptCreate

Whenever Sentry captures a new issue, meaning the first occurrence of an error, enrich it with recent deploy context from Heroku and route it for triage. Begin by reading the Sentry issue and capturing the error title, the culprit (the file, function, or transaction where it fired), the severity level, roughly how many events it has, when it first appeared, and the permalink back to the issue in Sentry.

I keep a mapping of which Heroku app corresponds to each Sentry project, for example Sentry project 'api-prod' maps to Heroku app 'acme-api'. Use that mapping to choose the right Heroku app. Call Heroku's List Releases for that app to find the most recent deploy, then call Get Release on it for the full detail, including when it shipped, its version number, its description, and who deployed it.

Judge whether this error likely came from that release based on how recently it shipped relative to when the error first appeared. If the error first appeared within 30 minutes of the last deploy, flag it as likely deploy-related. If the last deploy was hours or days before the error first appeared, treat the correlation as weak and say so plainly. Always state how long ago the last release shipped.

Post an enriched alert to Slack using Slack Bot's Send a Message to my engineering channel. Include the error title, the culprit, whether the error correlates with the last Heroku deploy and how long ago that deploy shipped, and a link back to the issue in Sentry. Use Slack formatting so the error title and the correlation verdict stand out.

Then open a triage ticket in GitHub using Create an Issue in my tracking repository. Give it a clear title and a body that carries the full error context (title, culprit, severity, first seen, event count, and the Sentry link) alongside the deploy context (the last release version, when it shipped, and your correlation verdict). Before filing, you may check the repository's open issues so you do not duplicate a ticket that already exists for this error.

Skip opening a GitHub issue for low-severity errors or clearly duplicate noise, such as an error that is obviously a repeat of something already filed. In those cases still post the Slack alert, but note that no ticket was opened and briefly why. Treat errors that first appeared within 30 minutes of a deploy as likely deploy-related when you write both the alert and the ticket.

Example output

New Sentry error: TypeError: Cannot read properties of undefined (reading 'id') Culprit: checkout/PaymentForm.tsx in submitOrder Likely deploy-related: your last Heroku release (v482) shipped 12 minutes before this error first appeared. Severity: error, 34 events View in Sentry: https://sentry.io/organizations/acme/issues/... Triage ticket opened: acme/webapp#1290

Additional information

What does this prompt do?
  • Watches Sentry for brand-new errors and reads the details the moment one appears.
  • Checks your most recent Heroku deploy and judges whether it likely caused the error, based on how close in time they are.
  • Posts a clear alert to Slack with the error, the deploy verdict, how long ago it shipped, and a link back to Sentry.
  • Opens a triage ticket in GitHub with the full error and deploy context, and skips ticket-making for low-severity or duplicate noise.
What do I need to use this?
  • A Sentry account where your errors are tracked.
  • A Heroku account for the app that Sentry is monitoring.
  • A Slack workspace and the channel where you want alerts to land.
  • A GitHub repository where triage tickets should be filed.
  • A quick note of which Heroku app matches each Sentry project.
How can I customize it?
  • Change the time window that counts as deploy-related (the default flags errors that first appeared within 30 minutes of a deploy).
  • Pick which Slack channel gets the alerts and which GitHub repository gets the tickets.
  • Adjust which errors are worth a ticket, so low-severity or repeat noise stays out of GitHub.

Frequently asked questions

How does it know if the last deploy caused the error?
It compares when the error first appeared to when your most recent Heroku release shipped. If the error showed up within about 30 minutes of the deploy, it flags the release as the likely cause, and it always tells you how long ago that deploy went out.
Will it open a GitHub ticket for every single error?
No. It skips low-severity errors and obvious duplicate noise, so your issue tracker only fills up with things worth triaging. You still get the Slack alert in those cases.
How does it know which Heroku app goes with which Sentry project?
You tell it once. You provide a simple mapping of Sentry project to Heroku app, and it uses that to look up the right deploy history.
Does it post to Slack as me?
No. It posts as an automated Slack app to the channel you choose, so the alerts are clearly automated and stay separate from your own messages.
Can I use this if my app is not on Heroku?
This version is built around Heroku deploys. If your app ships through a different platform, the same idea can be rebuilt with that platform's release history.

Stop guessing whether the last deploy broke production.

Every new Sentry error arrives with the deploy context and triage ticket your on-call team needs to move fast.