Notifications and integrations

Connect Slack, GitHub, and email so tests speak up where your team already lives.

View as Markdown

Integrations connect Testsnag to the tools your team already lives in. The Integrations page is where you connect them once at the account level. The Settings page on each test or suite is where you decide exactly when each one fires. Keeping connection separate from configuration is the key idea, because you connect Slack to your workspace once, then per test you choose which channel each test posts to and whether it posts on success, on failure, or both.

  1. 1Connected integrations show a green marker. Connect once here, then configure per test.
  2. 2Disconnect revokes access for the whole workspace, not just one test.
  3. 3GitHub goes further than notifications: it can trigger runs on deployment events.

Slack

Slack is the most common connection. Once your workspace is connected, every test and suite gets per-channel options for notify-on-success and notify-on-failure. A typical setup is to send only failures to a noisy alerts channel, and to send fuller reports to a quieter team channel. Different tests can post to different channels, so a marketing-site smoke test can talk to the marketing team while a checkout test talks to engineering, all from the same Slack connection.

GitHub

GitHub goes further than just notifications. Connect the GitHub App, point a test at a repository, and Testsnag can run the test on deployment events from that repo. With Check Runs enabled, the result is posted back to the commit so it shows up in pull requests and deployment history, and you can wire branch protection rules to require it. An optional environment filter limits this to specific deployment environments such as production only.

Email

Email is also available as a toggle integration, with separate notify-on-success and notify-on-failure switches per test or suite. That makes it useful for teams who want alerts without adding another chat integration. Some other integration cards may appear in the UI as beta. Treat those as upcoming or limited-availability features rather than something to rely on for production workflows unless your team has explicitly enabled them.

How it fits together

The principle across all of them is simple: account-level integrations are connected once, then configured per test. You do not have to reconnect Slack every time you want a single test to post somewhere new, and disconnecting an integration cleanly turns off its notifications without deleting your per-test settings. If you reconnect later, the previous configuration is still there waiting.

Still stuck, or spotted something out of date?

Contact support