Bugsink 1.6: Slack Alerts

Klaas van Schelven
Klaas van Schelven; June 11 - 4 min read
Developer Setting up Slack Messaging in Bugsink

Bugsink 1.6 is out. It adds webhook-based alerts, starting with Slack. You can now send notifications to a chat channel instead of email. Other integrations can follow the same pattern. This release also includes various small improvements, including better log formatting, health checks, and sourcemap fixes.

Why you might want this

  • You already use Slack (or a compatible tool) to discuss incidents.
  • You want alerts to reach a team, not just individual inboxes.
  • You’d prefer to avoid email entirely for error notifications.
  • You’re worried about flooding your SMTP server with alerts.

How it works

You can now configure any number of webhook endpoints in your Bugsink instance. Each one receives alerts for the project it’s connected to. These aren’t tied to individual users—chat tools already have their own permission models.

To set up a Slack webhook, you need to create an incoming webhook in your Slack workspace. This is done in the Slack API console, and it’s straightforward. You can find the documentation in Slack’s API docs.

The main idea is that you first create a Slack app, then add an incoming webhook to it:

Setting up a Slack webhook
Setting up a Slack webhook Slack-side

Once you have the webhook URL, you can add it to Bugsink. Click on the megaphone icon in the project-list (it should be visible if you’re an admin of the project):

Megaphone icon in Bugsink
Click the megaphone icon to add a webhook in Bugsink

Then, click the “add” button and paste the webhook URL you got from Slack. You can also give it a name, so you can distinguish between different webhooks later on.

Adding a webhook in Bugsink
Click the megaphone icon to add a webhook in Bugsink

In the list of webhooks, you’ll see a test button. Click it to send a test message to Slack. If everything is configured correctly, you should see a “TEST issue” appearing in Bugsink. You can also simply wait until a real issue occurs, and it will be sent to Slack automatically.

Slack alert message
Example of a Slack alert message

Design considerations

  • No abstraction layer Several people pointed me to Apprise or Notifiers – generic libraries that support many notification backends. I looked into both, but decided not to use them. The differences between messaging platforms are big enough that proper support usually means handling each one individually.

  • Webhooks are configured per project, not per user Bugsink doesn’t allow per-user configuration to model who should receive which alert. Instead, it sends project-level alerts to the configured webhook endpoints. The idea is that visibility and filtering happen in the chat tool itself – through channel setup, user presence, and notification settings. That keeps the system simple and avoids duplicating logic that already exists elsewhere.

  • New or worsening issues only You’ll be notified for any state change that makes things worse, namely: new issues, regressions and unmuted issues.

What’s next

Bugsink 1.6 is just the first step toward better chat-ops support. Here are some ideas for future improvements:

  • More integrations The Slack integration in #3 opened the door to supporting other chat tools. There’s no abstraction layer—just a clear pattern: mimic what’s in alerts/service_backends/slack.py, make sure the kind is selectable, and you’re done. Frontend support for per-backend config is still missing (a small JS snippet), but that’s a one-time task. Suggestions are welcome (I’ll promote them to child issues), and PRs even more so.

  • Error delivery feedback Failed webhook deliveries currently show up in your Snappea logs, but not in the UI. It might make sense to surface these more clearly, especially for persistent or misconfigured endpoints.

  • Project-level email toggle This is now also relevant: a per-project setting to turn off email delivery completely. It’s been on the list for a while, but becomes more useful now that there’s an alternative channel for alerts.

  • Small adjustments to message content Once there’s some real usage, requests for tweaks will probably come in. These changes will be handled in code—not through a templating system.

Other Features & Fixes

Bugsink 1.6 also includes a bunch of smaller improvements:

  • Display formatted log message when available (See #111)
  • Add 2 env variables to compose-sample.yaml (See #110)
  • Add delete functionality for users (See #108)
  • Multi-file sourcemaps (See #87)
  • Lookup by debug_id in dicts: use UUID (See #105)
  • Add robots.txt that disallows crawling
  • Add HEALTHCHECK command to Dockerfiles (See #98)
  • Fingerprint: convert to string before concatenating (See #102)
  • Add /health/ready endpoint (See #98)

Backwards-Incompatible Change

The default number of web workers (in Docker) is now limited to min(cpu_count, 4). It used to be 10.

To revert to the old behavior, you can set the GUNICORN_CMD_ARGS environment variable in your docker invocation:

GUNICORN_CMD_ARGS="--workers=10"

Upgrading to Bugsink 1.6

Bugsink 1.6 is available now. Give it a try and let us know how it works for you!

See the full changelog on GitHub.

Upgrade now or install Bugsink for the first time.