Projects

Almost everything in Honeybadger is scoped to a project. We have some powerful configuration features to help you manage your errors.

At the top of the project page, there are tabs for the windows containing all aspects of the project.

General Project Settings

The General tab of the project settings page includes changing the name of the project and how long error occurrence data is retained. You can also enable or disable notifications by project environment. Environments are added to this list as errors are reported to our API from those environments.

The Resolve errors on deploy setting automatically marks all errors "resolved" when you report a deployment, causing new alerts to be sent for any errors that re-occur. When turned off, you can resolve individual errors on the next deploy from the actions area on the error page.

Below that is the project delete button - deleting a project cannot be undone!

Insights

The Insights tab shows your current Insights data limits and has a link to the Insights stats page, which can also be found by navigating to the API stats for a project.

To read more about configuring Insights, check out the Insights documentation page.

Users

From the Users settings tab, you can see and manage which users have access to the project and what teams are assigned to the project. This page also lets you see the members of each team currently assigned to the project.

Users can have admin privileges for a project if you add them individually while specifying the admin permission or if they have admin privileges on a team that is assigned to the project. Users having admin privileges at the account level (managed via the Users tab of the Account Settings page) will also have admin rights on the project.

To read more about user management, check out the User Management documentation page.

Alerts and Integrations

The Alerts and Integrations tab allows you to edit the notifications you receive as a user for the project. If you have admin privileges for the project, you can also manage the integrations (such as GitHub, Slack, etc.) that are connected to the project.

To read more about managing integrations, check out the Integrations documentation page.

API Keys

Project API keys grant access to our reporting APIs. The list of reporting endpoints is in our API docs. If an API key is leaked or misused, you can rotate your key by adding a new key and removing the old one.

Project Actions

Project Actions let you customize your errors as we receive them. Through actions, you can automatically:

• Assign errors to yourself or another team member
• Add tags
• Pause notifications
• Share errors publicly

One exciting usage example for Project Actions is assigning errors to specific code owners.

For example, Ben takes care of most of the billing code here at Honeybadger. It would make sense that he should be assigned any errors related to billing. Here is a simple setup to route StripeController errors to Ben:

You can run all your incoming errors through the actions, or you can use the query box to constrain which errors have actions applied to them. The query box works identically to the search box when navigating on the error tab.

Source Maps

Honeybadger can automatically un-minify your code if you provide a source map along with your minified JavaScript files. The tab for Source Maps in Project Settings allows you to choose whether or not to download your source maps. It also contains a list of the currently stored source maps and a debugging tool that you can use to diagnose problems with source map processing.

For more on source maps, check out the Source Maps documentation page.

Advanced Settings

Here you can manage some settings that modify the Honeybadger UI and the processing of your errors.

The User URL field can be used to add a link in the Honeybadger UI to a URL you specify (such as an internal admin tool) with the user ID populated from the context.user_id data in your error report. When this field is populated and an error notification includes the user_id data, a button labeled "View user" is added to the error detail page that you can use to click through to the User URL:

If your context includes the user ID in a field other than context.user_id, you can use the User search field setting to specify where in your payload the user ID exists. You can also use this to override what field should be used as your user ID — e.g., you could specify context.user_email if you'd prefer to use email addresses rather than IDs. Regardless of the field you use, that field's value will be stored as the user in the search index and displayed in the notice timeline list and elsewhere in the UI.

The throttle field allows you to set limit for the number of errors the project can receive per minute. This can be useful for preventing a noisy project (like one dedicated to a QA or staging environment) from consuming too much of your quota.

Public error pages

You can make an error public by clicking "Share URL" in the actions area of the error you want to share. We provide you with a unique URL to give to collaborators. This is great but can be cumbersome when sharing multiple errors. Public Error Pages are a place where collaborators can view shared errors.

Once you enable the Public Error Page (Project Settings > Advanced > Enable public dashboard), collaborators can find shared errors in a similar view as the error listing page (with some restrictions). This can be especially useful if you pair this feature with project actions.

One language per project

We often get asked if users can have multiple programming languages in a project. While it is technically possible, we recommend that you create a separate project for each application or repository.