Sentry ships an official GitHub Action for release tracking

Application monitoring has moved from a nice-to-have to a core part of the development workflow. Sentry’s new official GitHub Action targets the gap between writing code and shipping it to production, automating the release management steps that often get skipped or done manually.

The action performs four main tasks when added to a workflow:

  • Notifies Sentry of new releases
  • Enables Sentry’s Suspect Commits feature
  • Automatically uploads source maps for JavaScript projects
  • Sends email notifications when a deployment happens

Screenshot of Sentry Release GitHub Action

The key benefit is traceability after a deploy. When an error surfaces, Sentry can identify the exact commit that introduced it and flag the developer responsible, cutting down the time spent hunting for regressions.

Screenshot showing suspect commits

Adding the action to your workflow

Setup is a matter of adding the action to an existing GitHub Actions workflow file:

- name: Create Sentry release
  uses: getsentry/[email protected]
  env:
    SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
    SENTRY_ORG: ${{ secrets.SENTRY_ORG }}
    SENTRY_PROJECT: ${{ secrets.SENTRY_PROJECT }}
  with:
    environment: production

The action creates a new Sentry release and signals that you are deploying to the production environment, which removes the need for a separate release-creation step in your CI pipeline.

How the workflow changes with monitoring

Without a monitoring platform, a production error often stalls waiting for someone to claim it. With Sentry integrated into GitHub, the response loop becomes structured:

  • Sentry catches exceptions in production code
  • Sentry surfaces stack traces and points to the commit that caused the error
  • Developers fix the broken code in GitHub using the normal review process
  • Automated tests run before scheduling the release
  • The Sentry Release GitHub Action uploads source maps, configures suspect commits, and notifies Sentry of the deployment

Diagram showing a simple 500 error falls between four people

The contrast between these two approaches is what Sentry is selling: a defined path from error to fix instead of a game of hot potato among team members.

Diagram showing Sentry in action

A collaboration between platform teams

The action is the product of both companies using each other’s tools internally. GitHub’s engineering team uses Sentry for error tracking, and Sentry’s team builds on GitHub, so the integration reflects real-world usage rather than a theoretical workflow.