In addition to snoozing notifications for a number of occurrences or a fixed period, we have introduced a new way of snoozing errors. You can now snooze errors per application version. In this blog post, you'll learn all about it.
Snoozing options in Flare
Flare has powerful options to notify you when something goes wrong in your app. We provide notifications via email, Slack, SMS (through Nexmo), Discord, Microsoft Teams and webhooks.
For each of these channels, you can choose which notifications should be sent through them. These are the events we can notify you of
-
when an error occurs for the very first time
-
when an error occurs for the 1st, 10th, 100th, 1000th, 2000th, ... time
-
when an error that was marked as resolved, occurs again
-
...
Snoozing errors per application version
If you are aware of an error in an application, you might temporary not want to receive notifications concerning a particular error anymore. You do want to get notified again after you've deployed a fix for the error.
You can achieve this by sending the version number of your app whenever an error occurs. In Laravel projects, you can do this by calling determineVersionUsing on the Flare facade.
// in a service provider
use Facade\Ignition\Facades\Flare;
Flare::determineVersionUsing(function() {
return '1.0'; // return your version number here.
});
With Flare being aware of your application version, you can now snooze any errors sent to Flare for a particular version.

You will only get notified when the error comes in with another version number (probably after you've redeployed your app).
Automatically determining a version number
If you don't set a version number explicitly using determineVersionUsing, we can use a short commit hash if your application is served via a git repo.
For this to work, you'll need to set the reporting.collect_git_information to value true in the flare config file, so git information is sent to Flare.
Continue reading
One core, many clients: the new Flare JavaScript client architecture
We recently reshaped the Flare JavaScript client from a single browser library and a few thin framework specific packages into a small family of packages built on a shared, platform-agnostic core. This post explains why we did it, what the core package exposes, how the browser and Node SDKs are built on top of it, why the React, Vue, and Svelte packages sit one level higher, and how anyone can use the same core to write a Flare JS client for a platform we do not ship ourselves.
Dries
Logging is here!
Logging is now available for all Flare users! Send any log from your app to Flare and use our polished interface to filter and search your logs in real-time.
Jimi
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates