We regularly receive requests from Airbrake customers asking how they can more finitely control the number of errors they receive during a given billing cycle. In general, these requests originate from a need to have more flexibility or manage costs. With that in mind, Airbrake recently engineered a new “on-demand” billing engine and introduced On-Demand Errors. You can learn more about that here.
The feedback about On-Demand Errors so far has been roundly positive, as it allows our customers who are close to (or over) their monthly error quota to preserve all their errors without having to upgrade a full plan tier. But with that change has also come some good questions - most prominently:
"How can I control the volume of errors received
and keep an eye on costs?"
We’re glad you asked!
Currently, there are two easy ways to adjust the error volume for your Airbrake account with our new Usage Cap feature.
Exploring Usage Caps
With the introduction of On-Demand Errors, we launched a new feature that allows customers to set "usage caps" for errors. In other words, you can now set an upper limit or “cap” on the number of errors you want to receive in a given billing cycle.
For the sake of this blog, we are going to take a look at managing Usage Caps predominantly for errors - although the same principle applies to performance or APM events, as well. (We'll dive into that topic in a future blog post)
To that end, a Usage Cap can be set at either the account or project level, thereby giving you the ability to prioritize cost (the total number of errors received) vs. comprehensiveness (the number of errors received across your projects and account).
Account-level caps:
Account-level caps let customers determine the value of receiving on-demand errors versus the total cost. This can be implemented in a couple of ways:Set usage cap = to your monthly plan quota. This ensures that no additional monthly cost will be incurred above the cost of your base plan. This option effectively turns off On-Demand Errors. All errors sent from your app to Airbrake above your plan quota will be discarded. You will start seeing errors once again when your billing cycle resets.
Alternatively, if you see a sudden spike in errors that causes you to exceed your plan quota and you have set your Usage Cap to stop errors upon reaching your plan quota, you can adjust your Usage Cap to a value above your plan quota (see option 2, below). Within 15 minutes, errors will begin showing up again in your dashboard. However, any errors that were discarded while your Usage Cap was set to the plan limit cannot be recovered - only errors sent from your app after the Usage Cap is adjusted will be seen.
Set your Usage Cap to N value, where N is some number greater than the number of errors included in your plan. This option provides more flexibility and balances the ability to manage cost while having a built-in cushion against spikes in errors. Said another way, you can determine how much your business is willing to spend to ensure that you see all your errors if there’s a major issue impacting your users or a spike for some other reason. With that budget number in mind, you can calculate the right amount for your Usage Cap by dividing the total cost you are willing to spend in a billing cycle by the “per on-demand error” rate attached to your plan level.
Remove the Usage Cap entirely and let the errors flow. This option will ensure that you never miss another error from your app. All errors received from your app, including those that exceed your plan quota, will be delivered, and you will be charged a small discounted fee for every error until your billing cycle resets.
Project-level caps:
Along with account-level Usage Caps, you can further fine-tune how many on-demand errors Airbrake delivers by setting the Usage Cap on a project-by-project basis. Setting project-level caps has two key benefits:
- A runaway error in a single app won't consume your full plan quota and use up the errors you need to monitor other areas of your stack.
- Test/staging environments can be capped at a low level to preserve error volume for your more critical production apps.
When you’ve decided on a strategy for managing your Usage Caps, you can head on over to the Account & Billing section of your Airbrake Dashboard and adjust the settings according to your business needs.
Using Filters & Config settings
Usage Caps are great for the big picture and managing the unexpected, but what about those common, high-volume errors you never get around to fixing? Unchecked, they can use lots of error volume and your monthly quota.
Airbrake offers a broad set of filter and configuration options specifically designed to let you control which errors you send to Airbrake. With just a couple of lines of code, the Airbrake notifier can:
- Ignore specific errors you already know about
- Ignore error types (based on whatever attributes you know you don't care about)
- Send a subset of important errors, but which might spike from time to time
Each Airbrake notifier has its own simple instructions on setting up and using filters (example: here's the install doc for our Ruby notifier). If you can't find the instructions for your language/platform, shoot us a note at support@airbrake.io.
Special Requirements:
Speaking of our customer success and support team - we're here to help! While we've developed tools designed to give you control, but we know that each customer is unique. If you need help figuring out the right configuration of usage caps and filters, let us know. Or if a rogue error or two blows through your quota and you need a little extra, we can help. Or even if you have a great idea for additional tools and controls Airbrake can provide in the future, we’d love to hear it!
What's coming next?
Not to give too much away, but we're already hard at work on making On-Demand Error controls even more useful and refined. Keep on the lookout for features that will identify spikes, frivolous errors, and other unwanted error volumes, all of which you’ll be able to filter out “automagically" – ultimately saving you money and, more importantly, reducing clutter in your error feed.
