Rollbar's multi-project support allows your teams to set up their projects to best suit their needs. This is especially convenient for microservice architectures that have a large number of independent codebases. Each codebase will have its own range of settings and alerts, so each team can have lots of control over its Rollbar experience.
Each project has its own set of access tokens for various purposes such as reporting occurrences and using the Rollbar API. The
post_server_item tokens are used to send occurrences for front-end and back-end frameworks, respectively. The
write tokens are used for API calls.
One of the more important concerns for a Rollbar account administrator is occurrence volume. Since billing and overages are dictated by occurrences, it's crucial to maintain responsible consumption of your allotment. Project access tokens have built-in rate limiting; the rate limit is editable for each token.
Each project will have its own source control integration since projects usually have their own repositories. You will need to follow the instructions in this guide to get the full benefit of the integration, and this process will also enable the Versions feature for Advanced and Enterprise accounts. By completing this integration, you will have detailed information about the code in the stack traces of your items.
Notification rules control all of your alerting and issue tracking integrations, so it is very important to configure these responsibly and iterate on them as your project evolves. This article from the Rollbar Knowledge base reviews some best practices for configuring your notification rules.
Service links allow users to quickly navigate from an item detail menu to other tools and services without losing context. By creating templated links using project fields, users will have dynamically generated URLs for quick navigation to other Rollbar menus and external addresses.
There are 3 different service links in the screenshot above, each one pointing to a different website. The first link does a simple Google search for the item's exception message. The second link executes an RQL query to retrieve all occurrences with the same exception message as the item. The third link opens a Datadog APM search around the request URL from the item.
One easy way to reduce the amount of housekeeping efforts required for an account is to configure one or both of the auto-resolve options for items in your project. There are two options for auto-resolve, auto-resolving whenever there is a new deploy and auto-resolving inactive items after a certain time window. Each one is configurable by environment, giving you more control and allowing you to prioritize your higher environments.
This option essentially gives you a clean slate for a given project/environment whenever a new version of code is deployed. Any item that does not resurface after the deploy will stay resolved, regardless of whether or not it was actually fixed. This keeps users focused on the more frequent/impactful issues and reduces clutter caused by undergrouping.
The other option for auto-resolving in a Rollbar project is through a timer on inactive items. This essentially gives your items an expiration window, and all issues that fall out of that window are automatically resolved. You can set different time ranges for different environments, allowing you to focus more heavily on production issues.
Updated about 1 year ago