Unless your team is made up of programming legends who never make mistakes, and your app exists in a near crystalline state that can only be accessed from a second, perfected plane of reality, you’re going to see plenty of errors. Some of these will be major issues that will need your immediate or near-immediate attention. Some will be minor issues that you’d prefer to ignore for a while (and perhaps even forever). Some will throw tons of errors at you. Some won’t.
In this great conflagration of errors, there may be some that you prefer to ignore and leave untracked by Sentry. Why would you ever ignore an error?
Maybe your goal is to only surface errors and exceptions that are actionable, and you’re afraid your team may miss out on important errors because they’ve tuned them out due to all the noise.
Maybe it’s being thrown by a legacy browser you don’t support or caused by a wandering web crawler.
Maybe you’re seeing lots of errors from a particular release, already have all the info you need to fix those errors, and don’t want to be flooded by more of the same messages.
Maybe you ignore it for the same reason you ignore most other things: the error is minor, and looking at it is annoying.
Whatever the situation, we provide inbound filters that allow you to determine exactly which errors, if any, we should drop on the floor. It takes only a few clicks (or less) to create each of these filters, making this process far simpler than client-side filtering, which requires config change(s) to the Sentry SDK and a deploy for the filter to take effect.
Let’s take a quick look at each. Note that these features are available to every subscription level unless otherwise noted, and you can find these options by going to [Project] » Project Settings » Inbound Filters.
Filter by error message
Available to large and enterprise plans
Maybe you know of a specific error message or two that you just never want to see. Or maybe you’ve already seen 100 error messages about an issue you’re planning to handle this week and don’t need to see it anymore. Or maybe the issue is third-party library errors that you simply can’t do anything about. Enter it here, and it’ll go away.
This option supports glob pattern matching, enabling you to specify sets of errors using wildcard characters.
Filter errors from these releases
Available to large and enterprise plans
New releases are an exciting and, often, bug-filled time. If you launched some new changes and are being slammed by error messages, you can filter out those committed changes that are hammering you with errors and use the already received messages to fix the problems.
As above, this option supports glob pattern matching.
Filter errors from these IP addresses
Have a rogue client whose activity is throwing you tons of useless error messages? Add its IP address to this block list and ignore them either forever or until such a time as you want to see their errors again.
Filter out known web crawlers
Web crawlers know only one thing: crawling every site on the web. They don’t care what annoying, pointless errors they might encounter while poking around every corner of your site. Don’t want to see those? Turn this on.
Filter out known errors from legacy browsers
There aren’t too many people out there using Opera 14 and below. Or using Safari 4.2. Or IE 8. But add them all up, and the annoying issues caused by these rickety old browsers might be taking up space for error messages better spent on browsers you care about. Flip the appropriate switches, and we’ll ignore errors generated by these browsers altogether.
Filter out errors known to be caused by browser extensions
As helpful as it is to install an extension that announces sweet money-saving deals for Amazon or that changes every written reference you encounter about “the cloud” to “my butt,” plenty of extensions, which many users have probably even forgotten installing, throw unexpected and, usually, minor errors. We’re aware of many of the most common ones, and this setting allows you to drop them.
Filter out errors coming from localhost
It’s possible you might want to catch errors in code you’re running on your local dev-box. It’s also possible you don’t; turn this on and filter those out.
Inserting a little self-directed filtering into your monitoring can go a very long way to making Sentry an even more valuable service. Take a look at our inbound filter documentation to learn more or reach out to support if you have questions.
If you’d like to talk to us about fine-grained filtering for large or enterprise workloads, you can drop us a line, and we’ll get in touch right away.