Did the last Heroku deploy cause this Sentry error?

By General Input

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.

Integrations

  • Heroku
  • Sentry
  • Slack Bot
  • GitHub

Type

Agentic Task

Categories

  • Engineering

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.

Related prompts

Explore more prompts
A brand asset library your marketing team actually searchesTurn Mailjet email clicks into ranked HubSpot follow-upsClean out the Looker dashboards and Looks nobody opensLiveKit live operations console for room moderationWake up dormant Keap leads with a researched reasonLiveChat coverage board for planning next week's shiftsPhone routing control panel for LiveKit voice agentsLinkedIn Ads budget pacing dashboard for every client accountGive your team Looker numbers without buying more seatsPause marketing emails to escalated customers, then restore them