Announcing Flexible Notifications on Scalingo

We've had notifications on Scalingo for Slack and webhooks for more than a year now. While it got the job done, our customers wanted more control on the kind of notifications they want to receive and the medium used. That's why we completely revamped the notification settings to be as flexible as you want. In a few clicks you can cut out noise, by only sending notifications to the people that need them, and only the ones that are relevant, through the channel you want.

If you had already setup notitications in the past, do not worry, all former settings have been automatically migrated. So unless you want to take advantage of the new features, there are no actions required on your end. That being said, let’s have a closer look at what has changed and maybe you’ll want to change something after all.

What's new?

Okay, on to the new stuff. The whole stack has been revamped, from the way settings are stored, to the logics, all the way up to a nice and simple UI. There’s a lot of stuff that is not visible, but the first thing you’ll probably notice is that the UI takes a whole new approach to notifications. It’s no longer just a list of notification services you can turn on, but a much more flexible and logical way of looking at notifications.

How Notifications on Scalingo have been improved

The first thing you'll notice when visiting the "Notifications" tab of your applications is that you immediately see the list of all services we integrate with. Today it's Slack, Webhook, Rocket.Chat and email.

Only crash events by default to reduce noise

Nearly since the beginning of Scalingo, the owner and the collaborators of an application had been notified by email of when his app crashes. This behavior has been completely integrated into the new notification system. By default, each application gets a default email notifier which sends the app_crashed_repeated. That means that every time our scheduler detects that your application has crashed multiple times in a short duration (2nd, 5th and 12th crashes are notified), an email will be sent. Of course, this notifier can be customized, something which was not possible before. It is even removable, although it is not recommended. We have automatically created this default notifier of all existing apps, there is nothing to do on your side to benefit from the new system.

Using multiple notification services on Scalingo

Sometimes you need to notify two different audiences. Perhaps you want to notify the whole team when a new deployment is out, but crash events should only be sent to your on-call team. Now you can do that with Slack, webhooks, Rocket.Chat or by email by simply adding as many notifiers as you need.

Select Notification Events on Scalingo

For every notifier you define, you have the choice to select the exact set of events this notifier will react to. They are gathered in 3 groups: "Just the deployment event", "Send me everything" and "Let me select individual events". When this last choice is ticked, the list of events to choose from will expand, as shown in the screenshot below. You can find the complete list of events and their meaning in our documentation.

Email Notifications on Scalingo?

Email notification are now an integral part of the notifications system. You can choose the list of collaborators to notify. Email addresses defined in their profile will be automatically used. Extra addresses to notify can also be added. That could be handy if your teams have their own email aliases like notifications@example.com or i-m-crashing-help-me@example.com.

What’s next?

These changes released today are not only providing more flexibility and control, they are also setting the stage for more modularity in the future. Your preferred communication tool is missing? The list of events is not refined enough for your needs? We would love to hear from you if you think there are ways we can make notifications even better.