This is the full developer documentation for Honeybadger.io
# Honeybadger Docs
> Official Honeybadger documentation.
Honeybadger provides error tracking, uptime monitoring, logging, and application performance insights in one simple platform that helps developers understand and fix issues faster.
## Product guides
[Section titled “Product guides”](#product-guides)
[Error monitoring](/guides/errors/)Get notified when errors occur in your applications
[Insights & Logging](/guides/insights/)Analyze logs, error trends, patterns, and more
[Dashboards & APM](/guides/dashboards/)Customize your monitoring dashboards to spot trends
[Uptime monitoring](/guides/uptime/)Get notified when your API and website are unresponsive
[Check-ins](/guides/check-ins/)Tracking pings from scheduled tasks and cron jobs
[Deployments](/guides/deployments/)Viewing and tracking deployments
[Status pages](/guides/status-pages/)Give users insight into your system status
[Reports](/guides/reports/)Viewing and understanding reports
[Accounts](/guides/accounts/)Manage billing and users
[Projects](/guides/projects/)Projects contain your errors, check-ins & uptime
[Integrations](/guides/integrations/)Connect Honeybadger to your favorite tools
[User Management](/guides/user-management/)User membership for project, teams, and accounts
[User Settings](/guides/user-settings/)Your personal preferences
[Heroku](/guides/heroku/)Honeybadger + Heroku <3
## Client libraries (SDKs)
[Section titled “Client libraries (SDKs)”](#client-libraries-sdks)
[Ruby](/lib/ruby/)
[JavaScript](/lib/javascript/)
[PHP](/lib/php/)
[Python](/lib/python/)
[Elixir](/lib/elixir/)
[Java](/lib/java/)
[Go](/lib/go/)
[Cocoa](/lib/cocoa/)
[.NET/C#](/lib/dotnet/)
[Crystal](/lib/crystal/)
[Clojure](/lib/clojure/)
[Other platforms](/lib/other/)
# API documentation
> Complete API documentation for Honeybadger's REST and reporting APIs.
Honeybadger’s APIs allow you to report exceptions from your applications, monitor your scheduled tasks, and retrieve and update the data we generate from your app’s errors.
## Reporting
[Section titled “Reporting”](#reporting)
These endpoints are the core of Honeybadger and how you get your data into our system.
[Exceptions](/api/reporting-exceptions/)`api.honeybadger.io/v1/notices`
[Check-Ins](/api/reporting-check-ins/)`api.honeybadger.io/v1/check_in/:id`
[Deployments](/api/reporting-deployments/)`api.honeybadger.io/v1/deploys`
[Source Maps](/api/reporting-source-maps/)`api.honeybadger.io/v1/source_maps`
[Events](/api/reporting-events/)`api.honeybadger.io/v1/events`
## Data API
[Section titled “Data API”](#data-api)
The Data API can be used to access data stored in your Honeybadger account and to make changes to your account data.
[Faults](/api/faults/)
[Dashboards](/api/dashboards/)
[Uptime](/api/uptime/)
[Check-Ins](/api/check-ins/)
[Comments](/api/comments/)
[Deployments](/api/deployments/)
[Projects](/api/projects/)
[Teams](/api/teams/)
[Environments](/api/environments/)
[Accounts](/api/accounts/)
[Status Pages](/api/status-pages/)
# Accounts API reference
> API reference for managing account information and users.
In Honeybadger, all resources are tied to an account. A user may belong to one or more accounts (for instance, you can have a work account and a personal account). The Accounts API allows you to programmatically fetch details about your accounts.
## Get all accounts
[Section titled “Get all accounts”](#get-all-accounts)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/
```
Returns a list of all accounts the authenticated user belongs to.
```json
{
"results": [
{
"id": "Me3upk",
"email": "homerjsimpson@gmail.com",
"name": "homer",
"active": true,
"parked": false
},
{
"id": "9bYfrm",
"email": "homer.j@simpsons.io",
"name": "Work",
"active": true,
"parked": false
}
],
"links": {
"self": "http://localhost:3000/v2/accounts"
}
}
```
## Get info for one account
[Section titled “Get info for one account”](#get-info-for-one-account)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/ID
```
Returns info about an account, including the quota consumption for the current month. Each of the three sets of quota info is returned as an array of arrays, with one date & count pair for each day of the month, starting at midnight UTC on the first of the month. The different types of stats are as follows:
* Stored: The number of error notifications saved and available for display in the UI
* Limited: The number of notifications that were discarded due to throttling (429 responses)
* Ignored: Notifications discarded as a result of errors being flagged as ignored in the UI
The quota\_consumed value is a percentage, so `0.75` would mean 75% of the month’s quota has been consumed. The quota resets at the first of the month.
```json
{
"id": "Me3upk",
"email": "homerjsimpson@gmail.com",
"name": "homer",
"active": true,
"parked": false,
"quota_consumed": 0.75,
"api_stats": {
"stored": [
[ 1648767600, 116 ],
[ 1648771200, 65 ],
...
],
"limited": [],
"ignored": []
}
}
```
## Get a list of account users or user details
[Section titled “Get a list of account users or user details”](#get-a-list-of-account-users-or-user-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/ID/users
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/ID/users/ID
```
Returns all the users or a single user for the given account:
```json
{
"results": [
{
"id": 1,
"role": "Owner",
"name": "",
"email": "westley@example.com"
}
]
}
```
## Update a user
[Section titled “Update a user”](#update-a-user)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"user":{"role":"Admin"}}' https://app.honeybadger.io/v2/accounts/ID/users/ID
```
The list of valid fields is as follows:
| Field name | Type | Description |
| ---------- | ------ | ----------------------------------------------- |
| `role` | string | One of “Member”, “Billing”, “Admin”, or “Owner” |
## Remove a user from the account
[Section titled “Remove a user from the account”](#remove-a-user-from-the-account)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/accounts/ID/users/ID
```
## Create an invitation for a user to join an account
[Section titled “Create an invitation for a user to join an account”](#create-an-invitation-for-a-user-to-join-an-account)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' \
-d '{"invitation":{"email":"inigo@example.com"}}' \
https://app.honeybadger.io/v2/accounts/ID/invitations
```
You can specify these fields:
| Field name | Type | Description |
| ---------- | ------ | --------------------------------------------------------- |
| `email` | string | The invited user’s email address. |
| `role` | string | One of “Member”, “Billing”, “Admin”, or “Owner” |
| `team_ids` | array | Array of team ids to which the invited user will be added |
Returns the created user invitation:
```json
{
"id": 9,
"email": "inigo@example.com",
"created_by": {
"email": "westley@example.com",
"name": "Westley"
},
"accepted_by": null,
"role": "Member",
"accepted_at": null,
"created_at": "2013-01-08T15:42:16Z",
"team_ids": []
}
```
## Update an account invitation
[Section titled “Update an account invitation”](#update-an-account-invitation)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' \
-d '{"invitation":{"role": "Admin"}}' \
https://app.honeybadger.io/v2/accounts/ID/invitations/ID
```
You can specify either of these fields:
| Field name | Type | Description |
| ---------- | ------ | --------------------------------------------------------- |
| `role` | string | One of “Member”, “Billing”, “Admin”, or “Owner” |
| `team_ids` | array | Array of team ids to which the invited user will be added |
## Get an account invitation list or account invitation details
[Section titled “Get an account invitation list or account invitation details”](#get-an-account-invitation-list-or-account-invitation-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/ID/invitations
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/ID/invitations/ID
```
Returns a list of account invitations or a single account invitation for the given account:
```json
{
"results": [
{
"id": 9,
"email": "inigo@example.com",
"created_by": {
"email": "westley@example.com",
"name": "Westley"
},
"accepted_by": {
"email": "inigo@example.com",
"name": "Inigo Montoya"
},
"role": "Member",
"accepted_at": "2013-01-08T15:42:41Z",
"created_at": "2013-01-08T15:42:16Z",
"team_ids": []
}
]
}
```
## Delete an account invitation
[Section titled “Delete an account invitation”](#delete-an-account-invitation)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/accounts/ID/invitations/ID
```
# Alarms API reference
> API reference for managing Insights alarms with endpoints to create, read, update, and delete alarms and view their trigger history.
The Alarms API lets you programmatically manage [Insights alarms](/guides/insights/alarms/). All alarm endpoints are scoped to a project.
Notification channels for alarms are managed in the Honeybadger UI and can’t be set via the API.
## Get an alarm list or alarm details
[Section titled “Get an alarm list or alarm details”](#get-an-alarm-list-or-alarm-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/alarms
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/alarms/ID
```
The list endpoint returns results in a `results` array. The detail endpoint returns a single alarm:
```json
{
"id": "8f0dc2b1-4d9e-4b6a-9c3f-2e7a51d0c8aa",
"name": "High error rate",
"description": "Triggers when error count exceeds 100 in 5 minutes",
"state": "ok",
"query": "filter event_type::str == \"notice\"",
"stream_ids": ["a1b2c3d4e5f6"],
"evaluation_period": "5m",
"lookback_lag": "1m",
"trigger_config": {
"type": "alert_result_count",
"config": { "operator": "gt", "value": 100 }
},
"error": null,
"last_checked_at": "2026-02-04T09:10:00Z",
"next_check_at": "2026-02-04T09:15:00Z",
"created_at": "2026-01-31T14:22:18Z",
"updated_at": "2026-02-04T09:11:05Z",
"url": "https://app.honeybadger.io/projects/1/insights/alarms/42",
"project_id": 1
}
```
The response includes:
| Field name | Type | Description |
| ------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------- |
| `id` | string | The alarm’s UUID. Use this value in URLs for show, update, delete, and history requests. |
| `name` | string | The alarm name. |
| `description` | string | The alarm description. |
| `state` | string | The alarm’s current state: `"ok"` (trigger condition not met), `"alarm"` (triggered), or `"initial"` (not yet evaluated). |
| `query` | string | The [BadgerQL query](/guides/insights/badgerql/) the alarm evaluates. |
| `stream_ids` | array | The IDs of the Insights streams the alarm queries. |
| `evaluation_period` | string | How often the alarm is evaluated, as a duration string (`"5m"`, `"1h"`, `"1d"`). |
| `lookback_lag` | string | The delay before each evaluation to allow data to arrive (`"1m"`, `"0s"`). |
| `trigger_config` | object | The trigger condition. See [Trigger config](#trigger-config). |
| `error` | string | The error message if the alarm’s query failed to execute; `null` otherwise. |
| `last_checked_at` | string | ISO 8601 timestamp of the last evaluation. |
| `next_check_at` | string | ISO 8601 timestamp of the next scheduled evaluation. |
| `created_at` | string | ISO 8601 timestamp. |
| `updated_at` | string | ISO 8601 timestamp. |
| `url` | string | A link to the alarm in the Honeybadger UI. |
| `project_id` | integer | The project the alarm belongs to. |
## Create an alarm
[Section titled “Create an alarm”](#create-an-alarm)
```bash
curl -u AUTH_TOKEN: \
-X POST \
-H 'Content-type: application/json' \
-d '{
"alarm": {
"name": "High error rate",
"description": "Triggers when error count exceeds 100 in 5 minutes",
"query": "filter event_type::str == \"notice\"",
"evaluation_period": "5m",
"lookback_lag": "1m",
"trigger_config": {
"type": "alert_result_count",
"config": { "operator": "gt", "value": 100 }
}
}
}' \
https://app.honeybadger.io/v2/projects/ID/alarms
```
Returns `201 Created` with the alarm JSON shown above.
The request body must be wrapped in a top-level `alarm` object. These fields can be provided:
| Field name | Type | Description |
| ------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | string | Required. The alarm name. |
| `query` | string | Required. A [BadgerQL query](/guides/insights/badgerql/) that returns the data to monitor. The alarm system wraps the query to count matching results per evaluation period, so a bare `filter` works — see [Query guidelines](#query-guidelines) below. |
| `evaluation_period` | string | Required. How often the alarm is evaluated, as a duration string (`"5m"`, `"1h"`, `"1d"`). Minimum `1m`, maximum less than a week. |
| `trigger_config` | object | Required. The condition that triggers the alarm. See [Trigger config](#trigger-config). |
| `description` | string | Optional description. |
| `stream_ids` | array | Optional list of [Insights stream IDs](/api/streams/) to query. If omitted, the alarm queries all streams on the project. IDs that don’t belong to the project are ignored; if that leaves the list empty, the request fails with a `422`. Note these are stream IDs, not slugs — `"default"` is a slug and is ignored. |
| `lookback_lag` | string | Optional delay before each evaluation to allow data to arrive (`"1m"`, `"0s"`). |
A `422 Unprocessable Entity` response with an `errors` key is returned when the alarm is invalid — for example, a missing required field, an invalid BadgerQL query, or an unknown trigger type.
### Trigger config
[Section titled “Trigger config”](#trigger-config)
The `trigger_config` object defines when the alarm transitions to the alarm state:
| Field name | Type | Description |
| ----------------- | ------- | ----------------------------------------------------------------------------------------------------------------------- |
| `type` | string | The trigger type. Currently `"alert_result_count"`, which triggers based on the count of results returned by the query. |
| `config.operator` | string | The comparison operator: `"gt"`, `"gte"`, `"lt"`, `"lte"`, `"eq"`, or `"neq"`. |
| `config.value` | integer | The threshold to compare the result count against. Must be >= 0. |
Some examples:
```json
// Trigger when more than 50 events match the query
{ "type": "alert_result_count", "config": { "operator": "gt", "value": 50 } }
// Trigger when no events match (e.g., a missing heartbeat)
{ "type": "alert_result_count", "config": { "operator": "eq", "value": 0 } }
// Trigger when any events match
{ "type": "alert_result_count", "config": { "operator": "neq", "value": 0 } }
```
### Query guidelines
[Section titled “Query guidelines”](#query-guidelines)
The alarm system automatically wraps the query to count results per evaluation period, so the query should filter and/or aggregate events, and the system handles the final counting:
```plaintext
filter event_type::str == "notice"
filter status::int >= 500
filter event_type::str == "request.handled" and duration::int > 5000
```
Queries with `stats` also work — the system counts the result rows:
```plaintext
filter event_type::str == "notice" | stats count() as count by fault_id::int
```
## Update an alarm
[Section titled “Update an alarm”](#update-an-alarm)
```bash
curl -u AUTH_TOKEN: \
-X PUT \
-H 'Content-type: application/json' \
-d '{
"alarm": {
"name": "High error rate",
"query": "filter event_type::str == \"notice\"",
"evaluation_period": "10m",
"trigger_config": {
"type": "alert_result_count",
"config": { "operator": "gt", "value": 100 }
}
}
}' \
https://app.honeybadger.io/v2/projects/ID/alarms/ID
```
Returns `204 No Content` on success. The request body uses the same fields as [Create an alarm](#create-an-alarm). The submitted definition replaces the existing one, so include every field — even the ones you aren’t changing.
## Delete an alarm
[Section titled “Delete an alarm”](#delete-an-alarm)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID/alarms/ID
```
Returns `204 No Content` on success.
## Get alarm trigger history
[Section titled “Get alarm trigger history”](#get-alarm-trigger-history)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/alarms/ID/history
```
Returns the alarm’s past evaluations that changed its state:
```json
{
"triggers": [
{
"id": "d4c8a2f6-3b1e-4f7a-8c5d-9e0b2a6f1c3e",
"state": "alarm",
"result": { "count": 127 },
"created_at": "2026-02-04T09:05:00Z"
}
],
"links": {
"self": "...",
"prev": "...",
"next": "..."
}
}
```
Each entry in the `triggers` array includes:
| Field name | Type | Description |
| ------------ | ------ | ---------------------------------------------------------------- |
| `id` | string | The trigger event ID. |
| `state` | string | The state after the evaluation: `"ok"`, `"alarm"`, or `"error"`. |
| `result` | object | The query result that caused the state change. |
| `created_at` | string | ISO 8601 timestamp of the evaluation. |
Use the `page` query parameter to paginate; the `links` object contains URLs for the previous and next pages.
# Check-ins API reference
> API reference for managing check-ins with endpoints to create, read, update, and delete scheduled task and cron monitors.
## Get a check-in list or check-in details
[Section titled “Get a check-in list or check-in details”](#get-a-check-in-list-or-check-in-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/check_ins
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/check_ins/ID
```
Returns a list of check-ins or a single check-in for a project. There are two different types of check-ins, simple or cron, and the response varies a bit between the two types.
### Simple check-in
[Section titled “Simple check-in”](#simple-check-in)
```json
{
"state": "pending",
"schedule_type": "simple",
"reported_at": null,
"expected_at": null,
"missed_count": 0,
"grace_period": "5 minutes",
"id": "XXXXXX",
"name": "Hourly clean up",
"slug": "hourly-clean-up",
"url": "https://api.honeybadger.io/v1/check_in/XXXXXX",
"report_period": "1 hour"
}
```
### Cron check-in
[Section titled “Cron check-in”](#cron-check-in)
```json
{
"state": "reporting",
"schedule_type": "cron",
"reported_at": "2018-01-16T12:36:11Z",
"expected_at": "2018-01-17T12:36:11Z",
"missed_count": 0,
"grace_period": "",
"id": "YYYYYY",
"name": "Hourly check",
"slug": "hourly-check",
"url": "https://api.honeybadger.io/v1/check_in/YYYYYY",
"cron_schedule": "30 * * * *",
"cron_timezone": "UTC"
}
```
## Create a check-in
[Section titled “Create a check-in”](#create-a-check-in)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' -d '{"check_in":{"name":"Daily reports", "report_period":"1 day", "schedule_type":"simple"}}' https://app.honeybadger.io/v2/projects/ID/check_ins
```
This endpoint returns either the simple or cron check-in response described above, depending on the type of check-in you create.
These fields can be provided:
| Field name | Type | Description |
| -------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| name | string | |
| slug | string | Optional identifier for more human-friendly check-in URL. |
| schedule\_type | string | Valid values are “simple” or “cron”. If you specify “cron”, then the “cron\_schedule” field is required. |
| report\_period | string | For simple check-ins, the amount of time that can elapse before the check-in is reported as missing. E.g., “1 day” would require a hit to the API daily to maintain the “reporting” status. Valid time periods are “minute”, “hour”, “day”, “week”, and “month”: “5 minutes”, “7 days”, etc. |
| grace\_period | string | The amount of time to allow a job to not report before it’s reported as missing. Valid values are the same as the report\_period field. |
| cron\_schedule | string | For a `schedule_type` of “cron”, the [cron-compatible string](https://en.wikipedia.org/wiki/Cron#Overview) that defines when the job should be expected to hit the API. |
| cron\_timezone | string | The timezone setting for your server that is running the cron job to be monitored. The default value is “UTC”. Valid timezone values are listed [here](/api/check-ins/timezones/). |
## Update a check-in
[Section titled “Update a check-in”](#update-a-check-in)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"check_in":{"name":"Updated check-in name"}}' https://app.honeybadger.io/v2/projects/ID/check_ins/ID
```
The fields listed in the previous section other than `schedule_type` can be updated. In other words, the schedule type can’t be changed. The `report_period` field is only valid for simple check-ins, and the `cron_schedule` and `cron_timezone` fields are only valid for cron check-ins.
## Update all check-ins
[Section titled “Update all check-ins”](#update-all-check-ins)
Caution
Use this endpoint with caution, as it will delete all existing check-ins if you send an empty payload.
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"check_ins":[{"name":"Updated check-in name", "slug":"my-slug"}]}' https://app.honeybadger.io/v2/projects/ID/check_ins
```
Similar to updating a single check-in, this endpoint can be used to update multiple check-ins at once. All check-ins need to be unique by slug and by name (if provided). Any check-ins that do not have a matching slug or name will be created, and any check-ins that are not present in the request will be deleted.
The results will be an array of the updated check-ins and any check-ins that were created or deleted. The response will look like this:
```json
{
"results": [
{
"operation": "update",
"slug": "my-changed-slug",
"success": true
},
{
"operation": "create",
"slug": "my-changed-slug",
"success": false,
"errors": ["Slug is not unique"]
},
{
"operation": "delete",
"slug": "my-deleted-slug",
"success": true
}
]
}
```
## Delete a check-in
[Section titled “Delete a check-in”](#delete-a-check-in)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID/check_ins/ID
```
# Check-in timezone values
> Complete list of supported timezones for Honeybadger check-in scheduling and cron monitoring configuration.
Use the friendly name (like Pacific Time (US & Canada) instead of America/Los\_Angeles) when working with the API. The other labels are provided here for search-ability. 🙂
| Value for `cron_timezone` (use this) | AKA (don’t use this) |
| ------------------------------------ | ------------------------------- |
| UTC | Etc/UTC |
| Abu Dhabi | Asia/Muscat |
| Adelaide | Australia/Adelaide |
| Alaska | America/Juneau |
| Almaty | Asia/Almaty |
| American Samoa | Pacific/Pago\_Pago |
| Amsterdam | Europe/Amsterdam |
| Arizona | America/Phoenix |
| Astana | Asia/Dhaka |
| Athens | Europe/Athens |
| Atlantic Time (Canada) | America/Halifax |
| Auckland | Pacific/Auckland |
| Azores | Atlantic/Azores |
| Baghdad | Asia/Baghdad |
| Baku | Asia/Baku |
| Bangkok | Asia/Bangkok |
| Beijing | Asia/Shanghai |
| Belgrade | Europe/Belgrade |
| Berlin | Europe/Berlin |
| Bern | Europe/Zurich |
| Bogota | America/Bogota |
| Brasilia | America/Sao\_Paulo |
| Bratislava | Europe/Bratislava |
| Brisbane | Australia/Brisbane |
| Brussels | Europe/Brussels |
| Bucharest | Europe/Bucharest |
| Budapest | Europe/Budapest |
| Buenos Aires | America/Argentina/Buenos\_Aires |
| Cairo | Africa/Cairo |
| Canberra | Australia/Melbourne |
| Cape Verde Is. | Atlantic/Cape\_Verde |
| Caracas | America/Caracas |
| Casablanca | Africa/Casablanca |
| Central America | America/Guatemala |
| Central Time (US & Canada) | America/Chicago |
| Chatham Is. | Pacific/Chatham |
| Chennai | Asia/Kolkata |
| Chihuahua | America/Chihuahua |
| Chongqing | Asia/Chongqing |
| Copenhagen | Europe/Copenhagen |
| Darwin | Australia/Darwin |
| Dhaka | Asia/Dhaka |
| Dublin | Europe/Dublin |
| Eastern Time (US & Canada) | America/New\_York |
| Edinburgh | Europe/London |
| Ekaterinburg | Asia/Yekaterinburg |
| Fiji | Pacific/Fiji |
| Georgetown | America/Guyana |
| Greenland | America/Godthab |
| Guadalajara | America/Mexico\_City |
| Guam | Pacific/Guam |
| Hanoi | Asia/Bangkok |
| Harare | Africa/Harare |
| Hawaii | Pacific/Honolulu |
| Helsinki | Europe/Helsinki |
| Hobart | Australia/Hobart |
| Hong Kong | Asia/Hong\_Kong |
| Indiana (East) | America/Indiana/Indianapolis |
| International Date Line West | Etc/GMT+12 |
| Irkutsk | Asia/Irkutsk |
| Islamabad | Asia/Karachi |
| Istanbul | Europe/Istanbul |
| Jakarta | Asia/Jakarta |
| Jerusalem | Asia/Jerusalem |
| Kabul | Asia/Kabul |
| Kaliningrad | Europe/Kaliningrad |
| Kamchatka | Asia/Kamchatka |
| Karachi | Asia/Karachi |
| Kathmandu | Asia/Kathmandu |
| Kolkata | Asia/Kolkata |
| Krasnoyarsk | Asia/Krasnoyarsk |
| Kuala Lumpur | Asia/Kuala\_Lumpur |
| Kuwait | Asia/Kuwait |
| Kyiv | Europe/Kiev |
| La Paz | America/La\_Paz |
| Lima | America/Lima |
| Lisbon | Europe/Lisbon |
| Ljubljana | Europe/Ljubljana |
| London | Europe/London |
| Madrid | Europe/Madrid |
| Magadan | Asia/Magadan |
| Marshall Is. | Pacific/Majuro |
| Mazatlan | America/Mazatlan |
| Melbourne | Australia/Melbourne |
| Mexico City | America/Mexico\_City |
| Mid-Atlantic | Atlantic/South\_Georgia |
| Midway Island | Pacific/Midway |
| Minsk | Europe/Minsk |
| Monrovia | Africa/Monrovia |
| Monterrey | America/Monterrey |
| Montevideo | America/Montevideo |
| Moscow | Europe/Moscow |
| Mountain Time (US & Canada) | America/Denver |
| Mumbai | Asia/Kolkata |
| Muscat | Asia/Muscat |
| Nairobi | Africa/Nairobi |
| New Caledonia | Pacific/Noumea |
| New Delhi | Asia/Kolkata |
| Newfoundland | America/St\_Johns |
| Novosibirsk | Asia/Novosibirsk |
| Nuku’alofa | Pacific/Tongatapu |
| Osaka | Asia/Tokyo |
| Pacific Time (US & Canada) | America/Los\_Angeles |
| Paris | Europe/Paris |
| Perth | Australia/Perth |
| Port Moresby | Pacific/Port\_Moresby |
| Prague | Europe/Prague |
| Pretoria | Africa/Johannesburg |
| Puerto Rico | America/Puerto\_Rico |
| Quito | America/Lima |
| Rangoon | Asia/Rangoon |
| Riga | Europe/Riga |
| Riyadh | Asia/Riyadh |
| Rome | Europe/Rome |
| Samara | Europe/Samara |
| Samoa | Pacific/Apia |
| Santiago | America/Santiago |
| Sapporo | Asia/Tokyo |
| Sarajevo | Europe/Sarajevo |
| Saskatchewan | America/Regina |
| Seoul | Asia/Seoul |
| Singapore | Asia/Singapore |
| Skopje | Europe/Skopje |
| Sofia | Europe/Sofia |
| Solomon Is. | Pacific/Guadalcanal |
| Srednekolymsk | Asia/Srednekolymsk |
| Sri Jayawardenepura | Asia/Colombo |
| St. Petersburg | Europe/Moscow |
| Stockholm | Europe/Stockholm |
| Sydney | Australia/Sydney |
| Taipei | Asia/Taipei |
| Tallinn | Europe/Tallinn |
| Tashkent | Asia/Tashkent |
| Tbilisi | Asia/Tbilisi |
| Tehran | Asia/Tehran |
| Tijuana | America/Tijuana |
| Tokelau Is. | Pacific/Fakaofo |
| Tokyo | Asia/Tokyo |
| Ulaanbaatar | Asia/Ulaanbaatar |
| Urumqi | Asia/Urumqi |
| Vienna | Europe/Vienna |
| Vilnius | Europe/Vilnius |
| Vladivostok | Asia/Vladivostok |
| Volgograd | Europe/Volgograd |
| Warsaw | Europe/Warsaw |
| Wellington | Pacific/Auckland |
| West Central Africa | Africa/Algiers |
| Yakutsk | Asia/Yakutsk |
| Yerevan | Asia/Yerevan |
| Zagreb | Europe/Zagreb |
| Zurich | Europe/Zurich |
# Comments API reference
> API reference for managing error comments with endpoints to create, read, update, and delete resources.
## Get a comment list or comment details
[Section titled “Get a comment list or comment details”](#get-a-comment-list-or-comment-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/ID/comments
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/ID/comments/ID
```
Returns a list of comments or a single comment for the given fault with the following format:
```json
{
"id": 14,
"fault_id": 2,
"event": null,
"source": "unknown",
"notices_count": 0,
"created_at": "2012-08-22T15:47:26Z",
"author": "Inigo",
"body": "You killed my father; prepare to die"
}
```
## Create a comment
[Section titled “Create a comment”](#create-a-comment)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' -d '{"comment":{"body":"My comment"}}' https://app.honeybadger.io/v2/projects/ID/faults/ID/comments
```
The `body` field is the only field that can be included in the payload.
## Update a comment
[Section titled “Update a comment”](#update-a-comment)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"comment":{"body":"Updated comment"}}' https://app.honeybadger.io/v2/projects/ID/faults/ID/comments/ID
```
## Delete a comment
[Section titled “Delete a comment”](#delete-a-comment)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID/faults/ID/comments/ID
```
# Dashboards API reference
> API reference for managing Insights dashboards with endpoints to create, read, update, and delete dashboards and their widgets.
The Dashboards API lets you programmatically manage [Insights dashboards](/guides/dashboards/) and their widgets. All dashboard endpoints are scoped to a project.
## Get a dashboard list or dashboard details
[Section titled “Get a dashboard list or dashboard details”](#get-a-dashboard-list-or-dashboard-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/dashboards
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/dashboards/ID
```
The list endpoint returns results in a `results` array. The detail endpoint returns a single dashboard:
```json
{
"id": "abc123",
"title": "My Dashboard",
"widgets": [
{
"id": "4b2e9c1a-7f3d-4a12-9d5e-0b8f6a2c1e4d",
"type": "insights_vis",
"grid": { "x": 0, "y": 0, "w": 12, "h": 3 },
"presentation": { "title": "Total requests" },
"config": {
"query": "filter event_type::str == \"request\" | stats count() by bin()",
"vis": { "view": "line" },
"streams": ["default"]
}
}
],
"is_default": false,
"shared": true,
"default_ts": "P7D",
"created_at": "2026-01-31T14:22:18Z",
"updated_at": "2026-02-04T09:11:05Z",
"project_id": 1
}
```
The response includes:
| Field name | Type | Description |
| ------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `id` | string | The dashboard’s hashid. Use this value in URLs for show, update, and delete requests. |
| `title` | string | The dashboard title. |
| `widgets` | array | The dashboard’s widgets, in source form (see below). |
| `is_default` | boolean | Whether this is the project’s default dashboard. |
| `shared` | boolean | Whether the dashboard is shared with other users on the account. Dashboards created via the API are shared. |
| `default_ts` | string | The dashboard’s default time range, if set. See `default_ts` under [Create a dashboard](#create-a-dashboard) for accepted values. |
| `created_at` | string | ISO 8601 timestamp. |
| `updated_at` | string | ISO 8601 timestamp. |
| `project_id` | integer | The project the dashboard belongs to. |
In the response, each widget’s `config.streams` contains stream *slugs* (for example `"default"` or `"internal"`) rather than numeric stream IDs. Use the same slugs when creating or updating widgets.
## Create a dashboard
[Section titled “Create a dashboard”](#create-a-dashboard)
```bash
curl -u AUTH_TOKEN: \
-X POST \
-H 'Content-type: application/json' \
-d '{"dashboard":{"title":"My Dashboard","widgets":[]}}' \
https://app.honeybadger.io/v2/projects/ID/dashboards
```
Returns `201 Created` with the dashboard JSON shown above.
The request body must be wrapped in a top-level `dashboard` object. These fields can be provided:
| Field name | Type | Description |
| ------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `title` | string | The dashboard title. |
| `widgets` | array | The dashboard’s widgets. See the widget fields below. Pass an empty array to create a dashboard with no widgets. |
| `default_ts` | string | Optional default time range. Accepts an ISO 8601 duration (`P1D`, `P7D`, `PT1H`), a keyword (`today`, `yesterday`, `week`, `month`), or a date range (`2024-01-01/2024-01-31`). |
### Widget fields
[Section titled “Widget fields”](#widget-fields)
Each entry in the `widgets` array describes a single widget. The most common widget type is `insights_vis`, which renders a BadgerQL query as a chart or table:
| Field name | Type | Description |
| -------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | string | The widget type, e.g. `"insights_vis"`. Other built-in types include `"alarms"`, `"deployments"`, `"checkins"`, `"uptime"`, and `"errors"`. |
| `id` | string | Optional UUID. If omitted, the server generates one. Must be unique within the dashboard. On update, include the existing widget’s `id` to preserve it; omitting it will regenerate the ID. |
| `grid` | object | Position and size on the dashboard grid. Keys: `x`, `y`, `w`, `h`. Defaults to `{"x": 0, "y": 0, "w": 12, "h": 3}` if omitted. |
| `presentation` | object | Display options. Keys: `title`, `subtitle`. |
| `config` | object | Widget-specific configuration. See below. |
For `insights_vis` widgets, `config` accepts:
| Field name | Type | Description |
| ---------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `query` | string | A [BadgerQL query](/guides/insights/badgerql/) to execute. |
| `vis.view` | string | The visualization view. One of `"table"`, `"line"`, `"bar"`, `"area"`, `"pie"`, `"billboard"`, `"histogram"`, `"scatter"`, or `"heatmap"`. |
| `streams` | array | Optional list of stream slugs to query (for example `["default"]`). Defaults to all streams on the project. |
### Example with a widget
[Section titled “Example with a widget”](#example-with-a-widget)
```bash
curl -u AUTH_TOKEN: \
-X POST \
-H 'Content-type: application/json' \
-d '{
"dashboard": {
"title": "Traffic overview",
"widgets": [
{
"type": "insights_vis",
"grid": { "x": 0, "y": 0, "w": 12, "h": 3 },
"presentation": { "title": "Total requests" },
"config": {
"query": "filter event_type::str == \"request\" | stats count() by bin()",
"vis": { "view": "line" }
}
}
]
}
}' \
https://app.honeybadger.io/v2/projects/ID/dashboards
```
The request body is validated against the dashboard schema. A `422 Unprocessable Entity` response is returned when the payload violates the schema (unknown widget `type`, unknown properties, duplicate widget IDs, a title longer than 255 characters, etc.) or when the account’s dashboard or widget limit has been reached.
See the [Insights dashboards guide](/guides/dashboards/) for more on the widget catalog and schema. In the Honeybadger UI, the **Edit Source** view exposes the full YAML-equivalent of the same schema used by this API.
## Update a dashboard
[Section titled “Update a dashboard”](#update-a-dashboard)
```bash
curl -u AUTH_TOKEN: \
-X PUT \
-H 'Content-type: application/json' \
-d '{"dashboard":{"title":"Updated title","widgets":[]}}' \
https://app.honeybadger.io/v2/projects/ID/dashboards/ID
```
Returns `204 No Content` on success. The request body uses the same fields as [Create a dashboard](#create-a-dashboard). The submitted `widgets` array replaces the existing one, so include every widget you want to keep.
## Delete a dashboard
[Section titled “Delete a dashboard”](#delete-a-dashboard)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID/dashboards/ID
```
Returns `204 No Content` on success.
# Deployments API reference
> API reference for managing deployments with endpoints to read and delete resources.
## Get a deploy list or deploy details
[Section titled “Get a deploy list or deploy details”](#get-a-deploy-list-or-deploy-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/deploys
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/deploys/ID
```
Returns a list of deploys or a single deploy for the given project with the following format:
```json
{
"created_at": "2013-04-30T13:12:51Z",
"environment": "production",
"local_username": "deploy",
"project_id": 1,
"repository": "some/repo",
"revision": "2013-04-29-take-2-16-g6cf7eae"
}
```
The deploy list can be filtered with a number of URL parameters:
| Parameter | Description |
| ---------------- | --------------------------------------------------------- |
| `environment` | A string with the desired environment, e.g., ‘production’ |
| `local_username` | Username of the person doing the deployment |
| `created_after` | A Unix timestamp (number of seconds since the epoch) |
| `created_before` | A Unix timestamp (number of seconds since the epoch) |
| `limit` | Number of results to return (max and default are 25) |
The deploy list is always ordered by creation time descending.
## Delete a deploy
[Section titled “Delete a deploy”](#delete-a-deploy)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID/deploys/ID
```
# Environments API reference
> API reference for managing environments with endpoints to retrieve and configure environment-specific settings.
In Honeybadger, errors are grouped by the environment they occurred in. When an error is reported with a new environment, the environment is automatically stored, so you can search and filter by it in the future. You can also add, remove and manage your projects’ environments via the API.
## Get all environments
[Section titled “Get all environments”](#get-all-environments)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/PROJECT_ID/environments
```
Returns a list of all recorded environments in this project.
```json
{
"results": [
{
"id": 1,
"project_id": 1,
"name": "production",
"notifications": true,
"created_at": "2021-08-10T13:56:29.513358Z",
"updated_at": "2021-08-10T13:56:29.513358Z"
}
],
"links": {
"self": "http://localhost:3000/v2/projects/1/environments"
}
}
```
## Get a single environment’s details
[Section titled “Get a single environment’s details”](#get-a-single-environments-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/PROJECT_ID/environments/ID
```
```json
{
"id": 1,
"project_id": 1,
"name": "production",
"notifications": true,
"created_at": "2021-08-10T13:56:29.513358Z",
"updated_at": "2021-08-10T13:56:29.513358Z"
}
```
## Create an environment
[Section titled “Create an environment”](#create-an-environment)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' \
-d '{
"environment": {
"name": "Test",
"notifications": true
}
}' https://app.honeybadger.io/v2/projects/PROJECT_ID/environments
```
You can specify these fields within the `environment` object:
| Field name | Type | Description |
| --------------- | ------- | ---------------------------------------------------------------------- |
| `name` | string | The name of the environment |
| `notifications` | boolean | (Optional) Enable notifications for this environment. Default: `true`. |
Returns a 201 Created response containing the created environment’s details.
## Update an environment
[Section titled “Update an environment”](#update-an-environment)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' \
-d '{
"environment": {
"name": "Staging",
"notifications": false
}
}' https://app.honeybadger.io/v2/projects/PROJECT_ID/environments/ID
```
You can specify any of these fields within the `environment` object:
| Field name | Type | Description |
| --------------- | ------- | ----------------------------------------- |
| `name` | string | The name of the environment |
| `notifications` | boolean | Enable notifications for this environment |
Returns an empty response (204 No Content) if successful.
## Delete an environment
[Section titled “Delete an environment”](#delete-an-environment)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/PROJECT_ID/environments/ID
```
Returns an empty response (204 No Content) if successful.
# Errors API reference
> API reference for managing errors (faults) with endpoints to create, read, update, and delete error data.
Note
A **fault** is synonymous with an **error**, in that it contains a collection of **notices** (individual error events)
## Get a fault list or fault details
[Section titled “Get a fault list or fault details”](#get-a-fault-list-or-fault-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/ID
```
Returns a list of faults or a single fault for the given project with the following format:
```json
{
"action": "runtime_error",
"assignee": {
"email": "westley@honeybadger.io",
"id": 1,
"name": "Westley"
},
"comments_count": 0,
"component": "pages",
"created_at": "2013-01-22T16:33:22.704628Z",
"environment": "development",
"id": 2,
"ignored": false,
"klass": "RuntimeError",
"last_notice_at": "2013-02-11T19:18:31.991903Z",
"message": "This is a runtime error",
"notices_count": 7,
"project_id": 1,
"resolve_on_deploy": false,
"resolved": false,
"tags": ["internal"],
"url": "https://app.honeybadger.io/projects/1/faults/2"
}
```
The fault list can be filtered with a number of URL parameters:
| Parameter | Description |
| ----------------- | ---------------------------------------------------- |
| `q` | A [search string](/guides/errors/search/) |
| `created_after` | A Unix timestamp (number of seconds since the epoch) |
| `occurred_after` | A Unix timestamp (number of seconds since the epoch) |
| `occurred_before` | A Unix timestamp (number of seconds since the epoch) |
| `limit` | Number of results to return (max and default are 25) |
The fault list can be ordered with the order parameter in the URL, with the following possible values:
| Value | Description |
| ---------- | --------------------------------------------------------------- |
| `recent` | List the errors that have most recently occurred first |
| `frequent` | List the errors that have received the most notifications first |
The default order is by creation time.
If the search query affects the amount of matched notices, the `notices_count` field may not be accurate. For those cases, we add a `notices_count_in_range` field to the payload which reflects the notice counts with the query applied.
## Get a count of faults
[Section titled “Get a count of faults”](#get-a-count-of-faults)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/summary
```
Returns a total count of all the errors for a project and counts of errors grouped by environment, resolution status, and ignored status. The counts can be filtered by these parameters:
| Parameter | Description |
| ----------------- | ---------------------------------------------------- |
| `q` | A [search string](/guides/errors/search/) |
| `created_after` | A Unix timestamp (number of seconds since the epoch) |
| `occurred_after` | A Unix timestamp (number of seconds since the epoch) |
| `occurred_before` | A Unix timestamp (number of seconds since the epoch) |
For example, to get a count of open faults in production, you would use the `q` parameter to filter the results:
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/summary?q=environment%3Aproduction%20-is%3Aresolved%20-is%3Aignored
```
## Update a fault
[Section titled “Update a fault”](#update-a-fault)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"fault":{"resolved":true}}' https://app.honeybadger.io/v2/projects/ID/faults/ID
```
The following fields can be updated:
| Field name | Type | Description |
| ------------------- | ------- | ---------------------------------------------------------- |
| `resolved` | boolean | |
| `ignored` | boolean | |
| `assignee_id` | integer | |
| `resolve_on_deploy` | boolean | Mark the fault to be resolved automatically on next deploy |
Setting `resolved` or `ignored` to `true` in the same request takes precedence over `resolve_on_deploy`: the fault is resolved or ignored immediately and is not left marked for deploy. The current `resolve_on_deploy` state is also returned on each fault (see the fault details above).
## Delete a fault
[Section titled “Delete a fault”](#delete-a-fault)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID/faults/ID
```
## Get a count of occurrences for a fault
[Section titled “Get a count of occurrences for a fault”](#get-a-count-of-occurrences-for-a-fault)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/ID/occurrences
```
Provides the number of times errors have been encountered for a particular fault.
```json
[
[ 1510963200, 1 ],
[ 1511049600, 0 ],
[ 1511136000, 0 ],
[ 1511222400, 1 ],
...
]
```
The data can be filtered with these URL parameters:
| Parameter | Description |
| --------- | ------------------------------------------------------------ |
| `period` | One of “hour”, “day”, “week”, or “month”. Defaults to “hour” |
## Pausing and unpausing faults
[Section titled “Pausing and unpausing faults”](#pausing-and-unpausing-faults)
You can pause notifications for a period of time or for the number of occurrences of a fault. This doesn’t affect the resolved/unresolved status. If a fault is resolved while paused, new occurrences will still mark it as unresolved — you just won’t be notified about it. For time-based pauses, notifications resume on the first occurrence received after the time period has elapsed. For count-based pauses, notifications resume on the occurrence that exhausts the count. In both cases, a notification will be sent even if the fault was already reopened by an earlier occurrence during the pause.
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' -d '{"time":"day"}' https://app.honeybadger.io/v2/projects/ID/faults/ID/pause
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' -d '{"count":100}' https://app.honeybadger.io/v2/projects/ID/faults/ID/pause
```
Valid values for `time` are “hour”, “day”, and “week”, and valid values for `count` are 10, 100, and 1000.
You can clear the pause for a fault, or for all of a project’s faults:
```bash
curl -u AUTH_TOKEN: -X POST https://app.honeybadger.io/v2/projects/ID/faults/ID/unpause
curl -u AUTH_TOKEN: -X POST https://app.honeybadger.io/v2/projects/ID/faults/unpause
```
You don’t need to provide a request body for the unpause endpoints. The response body will be empty, and the status code will be 200.
## Bulk-resolving faults
[Section titled “Bulk-resolving faults”](#bulk-resolving-faults)
You can mark all faults for a project as resolved using this endpoint:
```bash
curl -u AUTH_TOKEN: -X POST https://app.honeybadger.io/v2/projects/ID/faults/resolve
```
The faults to be resolved can be filtered with the URL parameter `q`, which is a [search string](/guides/errors/search/).
Faults that are already resolved are skipped.
On success the response body is empty. The status code tells you whether the update was completed or was queued:
| Status | Meaning |
| ------ | -------------------------------------------------------------------------------- |
| 200 | Up to 1,000 faults matched. They were all resolved before the response was sent. |
| 202 | More than 1,000 faults matched. The work was queued and runs in the background. |
If the background work can’t be queued, the endpoint returns a 500 with an `errors` field, and nothing is resolved. Retry the request in that case.
## Linking faults to existing 3rd-party issues
[Section titled “Linking faults to existing 3rd-party issues”](#linking-faults-to-existing-3rd-party-issues)
```bash
curl -u AUTH_TOKEN: -H 'Content-type: application/json' -d '{"channel_id":123, "data":{"number":42}}' -X POST https://app.honeybadger.io/v2/projects/ID/faults/ID/link
```
This associates an existing GitHub issue, Pivotal Tracker story, etc. with a fault. Once associated, the error detail page in the UI will include a link to the associated issue. The `channel_id` portion of the payload can be obtained from the [integrations](/api/projects#get-a-list-of-integrations-for-a-project) API endpoint. The `data` portion of the payload varies depending on which type of integration is being referenced:
### GitHub
[Section titled “GitHub”](#github)
| Field name | type | Description |
| ---------- | ------- | -------------------------------------------------------------------------------------------- |
| `number` | integer | The issue number at the end of the issue URL: \*\* |
### Jira
[Section titled “Jira”](#jira)
| Field name | type | Description |
| ---------- | ------- | -------------------------------------------------------------------------------------------------- |
| `id` | integer | The issue id at the end of the issue URL: \*\* |
| `key` | string | The issue label: HB-123 |
| `self` | url | The issue URL: |
### Pivotal Tracker
[Section titled “Pivotal Tracker”](#pivotal-tracker)
| Field name | type | Description |
| ------------- | ------- | -------------------------------------------------------------------------------------------------- |
| `story_id` | integer | The story number at the end of the story URL: \*\* |
| `project_id` | integer | The Pivotal Tracker project ID |
| `pivotal_url` | url | The story URL: |
### Trello
[Section titled “Trello”](#trello)
| Field name | type | Description |
| ---------- | ------ | ------------------------------------------------------------------ |
| `id` | string | The card ID, e.g. 60ca3275a482444bcaae2a8a |
| `shortUrl` | url | Shortened version of the card URL: |
This endpoint is also used to update an existing link (e.g., to change the issue number for a linked GitHub issue).
## Unlinking faults
[Section titled “Unlinking faults”](#unlinking-faults)
```bash
curl -u AUTH_TOKEN: -H 'Content-type: application/json' -d '{"channel_id":123}' -X POST https://app.honeybadger.io/v2/projects/ID/faults/ID/unlink
```
This removes the link to an associated GitHub issue, Pivotal Tracker story, etc. The `channel_id` portion of the payload can be obtained from the [integrations](/api/projects/#get-a-list-of-integrations-for-a-project) API endpoint.
## Get a list of notices
[Section titled “Get a list of notices”](#get-a-list-of-notices)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/ID/notices
```
Returns a list of notices for the given fault with the following format:
```json
{
"created_at": "2013-02-11T19:18:31.123931Z",
"environment": {
"environment_name": "development",
"hostname": "apollo.local",
"project_root": {
"path": "/Users/bob/code/crywolf"
}
},
"cookies" { ... },
"fault_id": 2,
"id": "f78391e4-7789-49f0-888e-5f6c07a222f2",
"url": "https://app.honeybadger.io/projects/1/faults/2/d23e5f62-747f-11e2-a65e-4f2716edc8b7"
"message": "RuntimeError: This is a runtime error",
"web_environment": {
"CONTENT_LENGTH": "82",
"CONTENT_TYPE": "application/x-www-form-urlencoded",
"HTTP_USER_AGENT": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4",
...
},
"request": {
"action": "runtime_error",
"component": "pages",
"context": {
"cart_id": "8EF99AFC-B4DB-4FC5-A92A-9A6F86ABD364"
},
"params": {
"_method": "post",
"a": "1",
"action": "runtime_error",
"authenticity_token": "...",
"b": "2",
"controller": "pages"
},
"session": {
"_csrf_token": "...",
"session_id": "..."
},
"url": "http://example.com/pages/runtime_error?a=1&b=2",
"user": {
"email": "foo@bar.com",
"id": 1
}
},
"backtrace": [
{
"number": "4",
"file": "/Users/westley/code/crywolf/app/controllers/pages_controller.rb",
"method": "runtime_error"
},
...
],
"application_trace": []
}
```
The notice list can be filtered with these URL parameters:
| Parameter | Description |
| ---------------- | ---------------------------------------------------- |
| `created_after` | A Unix timestamp (number of seconds since the epoch) |
| `created_before` | A Unix timestamp (number of seconds since the epoch) |
| `limit` | Number of results to return (max and default are 25) |
The notice list is always ordered by creation time descending.
## Get a list of affected users
[Section titled “Get a list of affected users”](#get-a-list-of-affected-users)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/faults/ID/affected_users
```
Returns a list of the users who were affected by an error:
```json
[
{
"user": "bob@example.com",
"count": 4
},
{
"user": "ann@example.com",
"count": 1
}
]
```
The data can be filtered with the URL parameter `q`, which is a [search string](/guides/errors/search/).
# Data API
> Get started with Honeybadger's REST API including authentication, rate limits, and basic usage examples.
Our REST Data API can be used to access the data stored in your Honeybadger account and to make changes to your account data. To learn about reporting exception data, deployments, and other events, check out the [API](/api/) documentation.
## Glossary
[Section titled “Glossary”](#glossary)
The resource names used by the API may be different from those used in our web UI. Here is a glossary of the most important resource names:
* **Project:** A container that holds all your data for a single app or service.
* **Fault:** Called an “error” in the web UI. It has many Notices.
* **Notice:** Called an “error occurrence” in the web UI.
* **Site:** Called an “uptime check” in the web UI.
* **CheckIn:** Manages dead-man-switch checks.
* **Team:** Connects Honeybadger users to projects.
* **TeamInvitation:** Invites a user to join a team.
## Authentication
[Section titled “Authentication”](#authentication)
Authentication to the API is performed via [HTTP Basic Auth](http://en.wikipedia.org/wiki/Basic_access_authentication). Each request should be sent with your personal authentication token (available from [your profile page](https://app.honeybadger.io/users/edit)) as the basic auth username value. You do not need to provide a password.
For example, you can request your projects list with `curl` like so (the trailing colon after the token prevents curl from asking for a password):
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects
```
## Rate limiting
[Section titled “Rate limiting”](#rate-limiting)
You can make up to 360 requests per hour to our API. After you reach the limit for the hour, additional requests will receive a response with the 403 (Forbidden) status code. The following headers, returned with every API response, can provide you the information about your rate limit:
| Header | Description |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `X-RateLimit-Limit` | The number of requests that you can make per hour |
| `X-RateLimit-Remaining` | The number of requests you can make before getting an error |
| `X-RateLimit-Reset` | A Unix timestamp (number of seconds since the epoch) when remaining requests counter will be reset to the maximum |
## Format
[Section titled “Format”](#format)
The API returns JSON by default, but you should include `Accept: application/json` in your request headers. Lists of items are always paginated, even if there is only one page of results. The general response format for a list is as follows:
```json
{
"links": {
"self": "https://app.honeybadger.io/v2/...",
"next": "https://app.honeybadger.io/v2/..."
}
"results": [
{ ... },
{ ... }
]
}
```
You can get the page after the current page by loading the value found in the `next` element of the `links` hash and the page before the current page by loading the value found in the `prev` element of the links hash. Either or both of those elements may be missing from the links hash if we can determine there is no next page or previous page of results. On the other hand, there may be a next link that, when loaded, results in no records being found — in which case, the `results` top-level element will be an empty array.
## Requests and responses
[Section titled “Requests and responses”](#requests-and-responses)
When you create or update resources, send the request (via POST for creations or PUT for updates) with the `Content-type` header as application/json, the `Accept` header as application/json and the request body as a valid json object. No request body is required for deleting a resource via the DELETE method.
A successful POST request will return a 201 status code and the JSON representation of the just-created resource as the response body.
A PUT request that successfully updates an object will return a 204 status code with no response body.
Responses for successful DELETE requests return a status code of 204 and an empty response body.
Requests that result in errors will return a JSON response body like so:
```json
{ "errors": "Reason for error" }
```
The status code will be 403 if there is a permissions problem, 422 if the request was invalid, or in the 500 range if something unexpected happened.
# Insights API reference
> API reference for querying data with Insights.
## Query Insights data
[Section titled “Query Insights data”](#query-insights-data)
This endpoint executes a BadgerQL query against your project’s Insights data and returns the results.
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' -d '{"query":"fields @ts, @preview | limit 3"}' https://app.honeybadger.io/v2/projects/ID/insights/queries
```
The following fields can be provided in the request body:
| Field name | Type | Description |
| ------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `query` | string | A [BadgerQL query string](/guides/insights/badgerql/) to execute against your Insights data |
| `ts` | string | Optional timestamp range (defaults to `PT3H`). Accepts shortcuts (`today`, `week`) or ISO 8601 formats: durations (`P8D`), datetimes (`2021-12-14T22:14:08`), time intervals (`2021-12-10T00:00/2021-12-12T00:00`), or duration intervals (`P1W/P0D`). |
| `timezone` | string | Optional timezone for timestamp interpretation. Must be a valid IANA timezone identifier (e.g., `America/New_York`, `UTC`, `Europe/London`). |
| `stream_ids` | array | Optional list of [Insights stream IDs](/api/streams/) to query. Defaults to all streams on the project. IDs that don’t belong to the project are ignored. |
Returns the query results with the following format:
```json
{
"results": [
{
"@ts": "2025-11-18 11:40:05.802",
"@preview": "{\"ctx.class\":\"UptimeWorker\",\"ctx.elapsed\":0.297,\"ctx.jid\":\"aed85cd96b60c142b8c9b835\",\"lvl\":\"INFO\",\"msg\":\"done\",\"pid\":1,\"tid\":\"1knd\"}"
},
{
"@ts": "2025-11-18 11:40:05.812",
"@preview": "{\"ctx.class\":\"UptimeWorker\",\"ctx.elapsed\":0.198,\"ctx.jid\":\"dfb0be7609bb3d4747efb5fd\",\"lvl\":\"INFO\",\"msg\":\"done\",\"pid\":1,\"tid\":\"1kp5\"}"
},
{
"@ts": "2025-11-18 11:40:05.813",
"@preview": "{\"ctx.class\":\"FaultMetricWorker\",\"ctx.elapsed\":0.22,\"ctx.jid\":\"f1f3b3a9b9d874ba82e97590\",\"lvl\":\"INFO\",\"msg\":\"done\",\"pid\":1,\"tid\":\"1ksp\"}"
}
],
"meta": {
"query": "fields @ts, @preview | limit 3",
"fields": [
"@ts",
"@preview"
],
"schema": [
{
"name": "@ts",
"type": "datetime"
},
{
"name": "@preview",
"type": "json"
}
],
"row_count": 3,
"total_count": 3,
"start_at": "2025-11-18 11:11:26",
"end_at": "2025-11-18 14:11:26"
}
}
```
The response includes:
| Field name | Type | Description |
| ------------------ | ------ | ------------------------------------------------- |
| `results` | array | Array of objects containing the query results |
| `meta.query` | string | The query that was executed |
| `meta.fields` | array | List of fields included in the results |
| `meta.schema` | array | Schema information for each field (name and type) |
| `meta.row_count` | number | Number of rows returned in this response |
| `meta.total_count` | number | Total number of rows matching the query |
| `meta.start_at` | string | Start of the time range for the query |
| `meta.end_at` | string | End of the time range for the query |
Please see the [BadgerQL guide](/guides/insights/badgerql/) for the query syntax to use for the `query` field.
# Projects API reference
> API reference for managing projects with endpoints to create, retrieve, update, and delete resources, and fetch reports.
## Get a project list or project details
[Section titled “Get a project list or project details”](#get-a-project-list-or-project-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects?account_id=ACCOUNT_ID
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID
```
Returns a list or a single project with the following format:
```json
{
"active": true,
"created_at": "2012-06-09T20:33:27.798800Z",
"disable_public_links": false,
"earliest_notice_at": "2015-12-18T19:30:32.470689Z",
"environments": ["development", "production"],
"fault_count": 14,
"id": 1,
"last_notice_at": "2016-06-14T18:31:54.000000Z",
"name": "Rails exception tracking gem",
"owner": {
"email": "westley@honeybadger.io",
"id": 1,
"name": "Westley"
},
"purge_days": 30,
"resolve_errors_on_deploy": true,
"sites": [
{
"active": true,
"id": "9eed6a7e-af77-4cc6-8c55-7a5afa59a90b",
"last_checked_at": "2016-06-15T12:57:29.646956Z",
"name": "Main site",
"state": "up",
"url": "http://www.example.com"
}
],
"streams": [
{
"id": "a1b2c3d4e5f6",
"name": "Default",
"slug": "default",
"internal": false,
"project_id": 1,
"created_at": "2026-07-15T13:56:29.513358Z"
},
{
"id": "f6e5d4c3b2a1",
"name": "Internal",
"slug": "internal",
"internal": true,
"project_id": 1,
"created_at": "2026-07-15T13:56:29.513358Z"
}
],
"teams": [
{
"id": 1,
"name": "Team Marie"
}
],
"token": "098sflj2",
"unresolved_fault_count": 1,
"users": [
{
"email": "inigo@honeybadger.io",
"id": 2,
"name": "Inigo Montoya"
},
{
"email": "westley@honeybadger.io",
"id": 1,
"name": "Westley"
}
]
}
```
If the `account_id` parameter is not supplied when requesting the list of projects, all projects will be returned across all accounts to which the provided AUTH\_TOKEN has access.
`purge_days` is `null` when the project has no explicit retention setting of its own, in which case data is retained for the maximum number of days available to your subscription plan.
## Create a project
[Section titled “Create a project”](#create-a-project)
```bash
curl -u AUTH_TOKEN: \
-X POST \
-H 'Content-type: application/json' \
-d '{"project":{"name":"My project"}}' \
https://app.honeybadger.io/v2/projects?account_id=ACCOUNT_ID
```
Here is a list of the fields that can be provided:
| Field name | Type | Description |
| -------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | string | |
| `resolve_errors_on_deploy` | boolean | Whether all unresolved faults should be marked as resolved when a deploy is recorded |
| `disable_public_links` | boolean | Whether to allow fault details to be publicly shareable via a button on the fault detail page |
| `language` | string | One of “js”, “elixir”, “golang”, “java”, “node”, “php”, “python”, “ruby”, or “other” |
| `user_url` | string | A URL format like `"http://example.com/admin/users/[user_id]"` that will be displayed on the fault detail page and have \[user\_id] replaced with the user\_id from the fault’s context hash. |
| `source_url` | string | A URL format like `"https://gitlab.com/username/reponame/blob/[sha]/[file]#L[line]"` that is used to link lines in the backtrace to your git browser. This can be left blank if you provide the repository info in your deploy payloads or if you use the GitHub integration for your project. |
| `purge_days` | integer | The number of days to retain data (up to the max number of days available to your subscription plan). |
| `user_search_field` | string | A field such as “context.user\_email” that you provide in your error context. This field will be used to create the aggregated list of affected users. |
If the `account_id` query parameter is not provided, the project will be associated with the first account accessible by the user associated with the AUTH\_TOKEN.
## Update a project
[Section titled “Update a project”](#update-a-project)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"project":{"name":"Updated project name"}}' https://app.honeybadger.io/v2/projects/ID
```
The fields listed in the prior section are also available when updating a project.
## Delete a project
[Section titled “Delete a project”](#delete-a-project)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID
```
## Get a count of occurrences for all projects or a single project
[Section titled “Get a count of occurrences for all projects or a single project”](#get-a-count-of-occurrences-for-all-projects-or-a-single-project)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/occurrences
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/occurrences
```
Provides the number of times errors have been encountered in your project or across all your projects.
```json
[
[ 1510963200, 1440 ],
[ 1511049600, 1441 ],
[ 1511136000, 1441 ],
[ 1511222400, 1441 ],
...
]
```
The data is returned as an array of epoch seconds/count pairs, and it can be filtered with these URL parameters:
| Parameter | Description |
| ------------- | ------------------------------------------------------------ |
| `period` | One of “hour”, “day”, “week”, or “month”. Defaults to “hour” |
| `environment` | Limit results to this environment |
When the period is “hour” (the default), the data returned is the most recent 60 one-minute buckets. When it is “day”, the data comes from the most recent 24 one-hour buckets, and when it is “week” or “month”, the data is grouped into one-day buckets. All times and bucket boundaries are UTC.
## Get a list of integrations for a project
[Section titled “Get a list of integrations for a project”](#get-a-list-of-integrations-for-a-project)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/integrations
```
Returns a list of integrations (a.k.a. channels) for a project:
```json
[
{
"id": 9693,
"active": false,
"events": ["occurred", "assigned"],
"site_ids": ["605e7c8e-e6c8-4102-a8f8-37a9431ee78be"],
"options": {
"url": "http://requestb.in/7d87eae"
},
"excluded_environments": [],
"filters": [],
"type": "WebHook"
}
]
```
The `options` element varies depending on the type of integration.
## Get report data
[Section titled “Get report data”](#get-report-data)
The following endpoints provide the data that is displayed on the Reports tab for a project.
These URL parameters can be used to filter the data returned by each of the report endpoints:
| Parameter | Description |
| ------------- | ---------------------------------------------------------------------- |
| `start` | Date/time in ISO 8601 format for the beginning of the reporting period |
| `stop` | Date/time in ISO 8601 format for the end of the reporting period |
| `environment` | Limit results to this environment |
### Notices by class
[Section titled “Notices by class”](#notices-by-class)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/reports/notices_by_class
```
Returns a count of error notifications processed, grouped by class.
```json
[
["RuntimeError", 8347],
["SocketError", 4651]
]
```
### Notices by location
[Section titled “Notices by location”](#notices-by-location)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/reports/notices_by_location
```
Returns a count of error notifications processed, grouped by location. The location is framework-dependent; e.g., for Rails applications it’s a combination of the controller and the action.
```json
[
["inquiries#create", 2904],
["members#details", 862]
]
```
### Notices by user
[Section titled “Notices by user”](#notices-by-user)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/reports/notices_by_user
```
Returns a count of error notifications processed, grouped by user (assuming you are providing user\_id and/or user\_email in the context).
```json
[
["julia@example.com", 579],
["marie@example.com", 289]
]
```
### Notices by day
[Section titled “Notices by day”](#notices-by-day)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/reports/notices_per_day
```
Returns a count of error notifications processed, grouped by day (with days starting at midnight UTC).
```json
[
["2023-01-24T00:00:00.000000+00:00", 3161],
["2023-01-25T00:00:00.000000+00:00", 2620],
["2023-01-26T00:00:00.000000+00:00", 2852],
["2023-01-27T00:00:00.000000+00:00", 2502],
["2023-01-28T00:00:00.000000+00:00", 1759],
["2023-01-29T00:00:00.000000+00:00", 1420],
["2023-01-30T00:00:00.000000+00:00", 3027],
["2023-01-31T00:00:00.000000+00:00", 1624]
]
```
# Reporting check-ins
> API reference for reporting check-ins to Honeybadger to monitor scheduled tasks and cron jobs.
To report a check-in, simply send a GET request to the endpoint URL you received when creating the check-in:
```bash
curl https://api.honeybadger.io/v1/check_in/XyZZy
```
You can also send an email (no subject or body required) to `XyZZy@report.hbchk.in`, where `XyZZy` is the same (case-sensitive) ID from the endpoint URL.
If you specify a [slug](/guides/check-ins/#slugs) for a check-in, you can use that slug and the project’s API key in the URL rather than the ID:
```bash
curl https://api.honeybadger.io/v1/check_in/PROJECT_API_KEY/my_identifier
```
## Check-in payloads
[Section titled “Check-in payloads”](#check-in-payloads)
Business-tier accounts can send additional check-in details via POST. The payload is optional and must be under 20KB.
```bash
curl -X POST https://api.honeybadger.io/v1/check_in/XyZZy \
-H "Content-Type: application/json" \
-d '{
"check_in": {
"status": "success",
"duration": 1234,
"stdout": "backup completed",
"stderr": "",
"exit_code": 0
}
}'
```
The `check_in` object supports:
* `status` (string): `success` or `error`
* `duration` (integer): milliseconds
* `stdout` (string): captured standard output
* `stderr` (string): captured standard error
* `exit_code` (integer): process exit code
The data sent with the `check_in` object will be sent to [Insights](/guides/insights/) as part of the check-in event. You can find more information on using check-ins [here](/guides/check-ins/).
# Reporting deployments
> API reference for reporting deployments to Honeybadger.
Use this endpoint to notify Honeybadger when a deploy occurs. For an overview of all reporting methods, see the [Deployments guide](/guides/deployments/#reporting-deployments).
## POST /v1/deploys
[Section titled “POST /v1/deploys”](#post-v1deploys)
Make a POST request to `https://api.honeybadger.io/v1/deploys` with the following parameters:
| Parameter | Required | Description |
| ------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------- |
| api\_key | Required | Your project’s API key |
| deploy\[environment] | Optional | The environment name. Example: `production` |
| deploy\[revision] | Optional | The VCS revision being deployed. Could be a git hash, or a tag name. Example: `7cd4bac1bd7e2ddf858d10ee86e362c8d8e2f912` |
| deploy\[repository] | Optional | The base URL of the VCS repository. It should be HTTPS-style. Example: `https://github.com/honeybadger-io/honeybadger-ruby` |
| deploy\[local\_username] | Optional | The name of the user who is deploying. Example: `Jane` |
Example `curl` command:
```sh
HONEYBADGER_ENV="production" \
HONEYBADGER_REVISION="$(git rev-parse HEAD)" \
HONEYBADGER_REPOSITORY="$(git config --get remote.origin.url)" \
HONEYBADGER_API_KEY="Your project API key" \
&& curl -g "https://api.honeybadger.io/v1/deploys?deploy[environment]=$HONEYBADGER_ENV&deploy[local_username]=$USER&deploy[revision]=$HONEYBADGER_REVISION&deploy[repository]=$HONEYBADGER_REPOSITORY&api_key=$HONEYBADGER_API_KEY"
```
You can also send a JSON payload with `Content-Type: application/json`:
```bash
curl https://api.honeybadger.io/v1/deploys \
-H 'X-API-Key: Your project API key' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"deploy": {
"environment": "production",
"local_username": "sam",
"revision": "7cd4bac1bd7e2ddf858d10ee86e362c8d8e2f912",
"repository": "https://github.com/someuser/somerepo"
}
}'
```
A successful response returns `{"status":"OK"}`.
# Reporting events
> API reference for sending events to Honeybadger Insights for monitoring and analysis.
Events you send to this API will appear in [Honeybadger Insights](/guides/insights), where you can query and visualize the events.
Your [newline-delimited JSON](https://en.wikipedia.org/wiki/JSON_streaming#Newline-Delimited_JSON) payload should be submitted as the body of a POST request to with the following headers:
* X-API-Key: The API key from your project settings page
* Accept: application/json
* User-Agent: ”{{ Client name }} {{ client version }}; {{ language version }}; {{ platform }}”
Regarding the format of the User-Agent header, you can see an example of how that’s generated in our Ruby implementation [here](https://github.com/honeybadger-io/honeybadger-ruby/blob/991d7cb85ea3f224d6cf0943a87f690de9f9b051/lib/honeybadger/util/http.rb#L21), which generates a string like this: `HB-Ruby 2.1.1; 2.2.7; x86_64-linux-gnu`. If you don’t have all this information available to send, that’s OK, but the more the merrier. :)
If all went well with your POST, you’ll get a response with the status code 201 and information about the just-logged error as a JSON hash.
If all *didn’t* go well, you could get a response with one of these status codes:
| Status Code | Description |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `403` | Either the API key is incorrect or the account has been deactivated |
| `413` | The payload size was too large. The maximum acceptable size is 102,400 bytes |
| `422` | The payload couldn’t be processed. |
| `429` | The API key was valid, but the payload was not accepted because you hit a rate limit (i.e., we have received too much traffic for this API key). |
| `500` | Our bad! :) |
## Sample payloads
[Section titled “Sample payloads”](#sample-payloads)
Each line of the payload must be a single JSON object. The structure of the events you send to this endpoint is up to you, based on your use case. For example, if you wanted to send lines from an unstructured log, you could send a payload like this:
```json
{"ts": "2023-08-31T09:19:30Z", "message": "This is a log line"}
{"ts": "2023-08-31T09:19:30Z", "message": "This is another log line"}
```
We strongly recommend you send structured logs to make querying a better experience:
```json
{
"ts": "2023-08-31T16:17:57Z",
"level": "info",
"action": "health",
"controller": "PagesController",
"method": "GET",
"path": "/health",
"status": 200,
"duration": 322
}
```
Sending events in this way would make it easy to do analytical queries like average request duration, counts by request path, etc.
Of course, you aren’t limited to logs — you can track any kind of event that makes sense for your application:
```json
{"ts": "2023-08-31T14:31:05Z", "event": "user.signup", "user": {"id": 42, "source": "Daring Fireball Ad"}}
{"ts": "2023-08-31T14:33:05Z", "event": "company.created", "project": {"id": 54, "name": "Spacely Space Sprockets", "shared": true}}
```
You do not need to include a `ts` element in each JSON object, but if you do, it must be an [RFC3339](https://www.rfc-editor.org/rfc/rfc3339)-formatted timestamp. If `ts` is omitted, or if it can’t be parsed as a timestamp, it will be added or replaced with the value of the current time as of the payload being processed.
## Setting default fields with a query parameter
[Section titled “Setting default fields with a query parameter”](#setting-default-fields-with-a-query-parameter)
You can pass a `defaults` query parameter containing a URL-encoded JSON object, and its fields will be merged into every event in the batch:
```plaintext
POST https://api.honeybadger.io/v1/events?defaults={"environment":"production","region":"us-east-1"}
```
With that parameter, this payload:
```json
{"message": "This is a log line"}
{"message": "This is another log line", "environment": "staging"}
```
…is stored as:
```json
{"message": "This is a log line", "environment": "production", "region": "us-east-1"}
{"message": "This is another log line", "environment": "staging", "region": "us-east-1"}
```
Fields already present in an event always win — a default never overwrites data you send in the payload.
The `defaults` parameter has a few restrictions:
* It must be a flat JSON object; values must be strings, numbers, or booleans.
* The keys `event_type` and `ts` are reserved and will be ignored.
* It’s limited to 16 keys and 2kB (URL-decoded).
* The 100kB per-event size limit applies to events after defaults are merged.
An invalid `defaults` parameter never causes the request to fail: entries that break the rules above are dropped (an unparseable or oversized parameter is ignored entirely), and the events are ingested as sent.
## Sending events from log files and other sources
[Section titled “Sending events from log files and other sources”](#sending-events-from-log-files-and-other-sources)
Check out our instructions on how to add data from other sources, like your log files, Heroku apps, etc., in our [Insights Guide](/guides/insights#adding-data-from-other-sources).
## Limits
[Section titled “Limits”](#limits)
Nested JSON structures are supported, but limiting the nesting to 2 or 3 levels is best. Each event must be less than 100kB, and the total request size must be less than 5MB.
Information about the quotas for this endpoint can be found [here](/resources/quotas/#insights).
# Reporting errors
> API reference for reporting exceptions to Honeybadger with request formats, parameters, and response structures.
Your JSON payload should be submitted as the body of a POST request to , with the following headers:
* X-API-Key: The API key from your project settings page
* Content-Type: application/json
* Accept: application/json
* User-Agent: ”{{ Client name }} {{ client version }}; {{ language version }}; {{ platform }}”
Regarding the format of the User-Agent header, you can see an example of how that’s generated in our Ruby implementation [here](https://github.com/honeybadger-io/honeybadger-ruby/blob/991d7cb85ea3f224d6cf0943a87f690de9f9b051/lib/honeybadger/util/http.rb#L21), which generates a string like this: `HB-Ruby 2.1.1; 2.2.7; x86_64-linux-gnu`. If you don’t have all this information available to send, that’s OK, but the more the merrier. :)
If all went well with your POST, you’ll get a response with the status code 201 and information about the just-logged error as a JSON hash:
```json
{ "id": "6840eec9-6903-4f13-b511-b91ee46fda6a" }
```
You can use that ID to jump directly to the error in our UI:
E.g., `https://app.honeybadger.io/notice/6840eec9-6903-4f13-b511-b91ee46fda6a`
If all *didn’t* go well, you could get a response with one of these status codes:
| Status Code | Description |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `403` | Either the API key is incorrect or the account has been deactivated |
| `413` | The payload size was too large. The maximum acceptable size is 262,144 bytes (256KB) |
| `422` | The payload couldn’t be processed. Please note that we only do *minimal* checking of the payload when it hits our API. It’s entirely possible to get a 201 response, only to have the payload end up not being able to processed later in the pipeline and thus not show up in the UI. |
| `429` | The API key was valid, but the payload was not accepted because you hit a rate limit (i.e., we have received too much traffic for this API key). |
| `500` | Our bad! :) |
## Sample payload
[Section titled “Sample payload”](#sample-payload)
Your JSON will probably vary most from the example in the `request` key of the hash, which supplies info about the request made by the user, the web server environment, and so on. The `context` key of the `request` hash should have information about the logged-in user, if any, so that we can report on the users effected by application errors.
The `backtrace` key of the `error` hash is essential, as that is used for grouping similar errors together in the Honeybadger UI. The `class` and `message` keys of the `error` hash are displayed in the Honeybadger UI and used for posting errors to other services, like Github issues.
Here’s an annotated payload for your enjoyment:
```json
{
// Please use relevant values for the name, url, and version keys of the
// `notifier` key that point back to your code/package.
"notifier": {
"name": "Honeybadger Notifier",
"url": "https://github.com/honeybadger-io/honeybadger-ruby",
"version": "1.0.0"
},
// Here's where your exception's class, message tags and backtrace go.
// The `class` and `message` attributes are what make up the error's "title" that we display in the UI.
// The `fingerprint` attribute is an optional string that is used to force errors with the same fingerprint (regardless of error class, message, or location) to be grouped together.
// The `backtrace` is a ruby-style backtrace. If the `source` attribute is included for a backtrace line, it will be displayed as a snippet in the UI,
// Last but not least, `causes` is an optional list of causes for the error.
// Honeybadger displays causes in the order they are listed here.
"error": {
"class": "RuntimeError",
"message": "RuntimeError: This is a runtime error, generated by the crywolf app",
"tags": ["wubba"],
"fingerprint": "optional string to force errors with the same fingerprint to be grouped together",
"backtrace": [
{
"number": "4",
"file": "/crywolf/app/controllers/pages_controller.rb",
"method": "runtime_error",
"source": {
"2": "",
"3": " def runtime_error",
"4": " raise RuntimeError.new(\"This is a runtime error, generated by the crywolf app\")",
"5": " end",
"6": ""
}
},
{
"number": "4",
"file": "/gems/1.9.3-p194/lib/ruby/gems/1.9.1/gems/actionpack-3.2.8/lib/action_controller/metal/implicit_render.rb",
"method": "send_action"
}
],
"causes": [
{
"class": "StandardError",
"message": "StandardError: This is the first cause",
"backtrace": [
{
"number": "8",
"file": "/crywolf/app/models/page.rb",
"method": "find"
},
{
"number": "13",
"file": "/crywolf/app/services/find.rb",
"method": "call"
}
]
}
]
},
// `breadcrumbs` are any interesting events that happened within the request leading up to the error
"breadcrumbs": {
"enabled": true,
"trail": [
{
"category": "query",
"message": "Active Record",
"metadata": {
"sql": "SELECT ?.? FROM ? ORDER BY ?.? ASC",
"connection_id": 14200,
"duration": 0.0001449
},
"timestamp": "2021-03-11T23:08:45.448Z"
},
{
"category": "request",
"message": "Action Controller Start Process",
"metadata": {
"controller": "PagesController",
"action": "home",
"format": "html",
"method": "GET",
"path": "/pages/home",
"duration": 0.0000136
},
"timestamp": "2021-03-11T23:08:45.451Z"
},
{
"category": "render",
"message": "Action View Template Render",
"metadata": {
"identifier": "/usr/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.5/lib/action_dispatch/middleware/templates/rescues/ diagnostics.html.erb",
"layout": "rescues/layout",
"duration": 0.0092867
},
"timestamp": "2021-03-11T23:08:45.554Z"
},
{
"category": "error",
"message": "RuntimeError",
"metadata": {
"exception_message": "This is a runtime error, generated by the crywolf app"
},
"timestamp": "2021-03-11T23:08:45.555Z"
},
{
"category": "notice",
"message": "Honeybadger Notice",
"metadata": {
"exception": "This is a runtime error, generated by the crywolf app"
},
"timestamp": "2021-03-11T23:08:45.555Z"
}
]
},
// `request` contains information about the HTTP request that caused this exception.
"request": {
// We display this data on the error's details page.
// `user_id` and `user_email` are special keys that are used to generate the "affected users" list in the UI.
"context": {
"user_id": 123,
"user_email": "test@example.com"
},
// In rails this is the Controller.
"component": "pages",
// In rails this is the Action.
"action": "runtime_error",
// The URL where the error occurred
"url": "http://crywolf.dev/pages/runtime_error?a=1&b=2",
// These are displayed under "params" on the error detail page
"params": {
"_method": "post",
"authenticity_token": "tuZ7y1PUEMadgKevSzgSUK6T0p267I1+NL0+rnR7xrI=",
"a": "1",
"b": "2",
"controller": "pages",
"action": "runtime_error"
},
// These are displayed under "session" on the error detail page
"session": {
"session_id": "57fb796258046e92b3201ece44531320",
"_csrf_token": "tuZ7y1PUEMadgKevSzgSUK6T0p267I1+NL0+rnR7xrI="
},
// These are displayed under "web environment" on the error detail page.
// Normally you'll just include the environment variables set by your web server.
"cgi_data": {
"REQUEST_METHOD": "POST",
"PATH_INFO": "/pages/runtime_error",
"QUERY_STRING": "a=1&b=2",
"SCRIPT_NAME": "",
"REMOTE_ADDR": "127.0.0.1",
"SERVER_ADDR": "0.0.0.0",
"SERVER_NAME": "crywolf.dev",
"SERVER_PORT": "80",
"HTTP_HOST": "crywolf.dev",
"HTTP_CONNECTION": "keep-alive",
"CONTENT_LENGTH": "82",
"HTTP_CACHE_CONTROL": "max-age=0",
"HTTP_ORIGIN": "http://crywolf.dev",
"HTTP_USER_AGENT": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.4",
"CONTENT_TYPE": "application/x-www-form-urlencoded",
"HTTP_ACCEPT": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"HTTP_REFERER": "http://crywolf.dev/",
"HTTP_ACCEPT_ENCODING": "gzip,deflate,sdch",
"HTTP_ACCEPT_LANGUAGE": "en-US,en;q=0.8",
"HTTP_ACCEPT_CHARSET": "ISO-8859-1,utf-8;q=0.7,*;q=0.3",
"HTTP_COOKIE": "_crywolf_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJTU3ZmI3OTYy",
"REMOTE_PORT": "52509",
"ORIGINAL_FULLPATH": "/pages/runtime_error?a=1&b=2"
}
},
"server": {
// The directory where your code lives. This helps us to display more concise paths.
"project_root": "/Users/josh/code/crywolf",
// Your environment name
"environment_name": "development",
// The server's hostname
"hostname": "Josh-MacBook-Air.local",
// Optional: Git sha for the deployed version of the code, for linking to GitHub, Gitlab, and BitBucket
"revision": "920201a",
// Optional: ID of the process that raised the error
"pid": 1138
}
}
```
## Payload tester
[Section titled “Payload tester”](#payload-tester)
While you’re developing an error collector in your language of choice that talks to our API, you can use our [payload tester](https://app.honeybadger.io/notice/test) to see how your payloads will be rendered in our UI.
# Uploading source maps
> API reference for uploading source maps to Honeybadger to get readable stack traces from minified JavaScript code.
Honeybadger can automatically un-minify your JavaScript code if you provide a [source map](https://web.dev/articles/source-maps) along with your minified files. Use the Source Map Upload API to upload your source maps to Honeybadger. See [Using Source Maps](/lib/javascript/errors/using-source-maps/) to learn more.
## Overview
[Section titled “Overview”](#overview)
To upload your source map files to Honeybadger, POST them to `https://api.honeybadger.io/v1/source_maps` with the following parameters:
| Param | Required | Description |
| -------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `api_key` | Required | The API key of your Honeybadger project (see the API Key tab in project settings). |
| `minified_url` | Required | The URL of your minified JavaScript file in production. `*` can be used as a [wildcard](#wildcards). Must be an absolute URL (query strings are ignored). |
| `minified_file` | Required | The minified file itself. |
| `source_map` | Required | The source map for your minified file. |
| revision | Optional, default: `master` | The deploy revision (i.e. commit sha) that your source map applies to. This could also be a code version. For best results, set it to something unique every time your code changes. The `revision` option must also be configured in [honeybadger.js](/lib/javascript/reference/configuration/). |
| \ | Optional | One or more additional source files which may be referenced by your source map. The name should be the URL that would normally be used to access the file, and the value should be the file itself. Many source map generators include the sources in the `sourcesContent` key inside the source map, so you may not need to send these. `*` in the name can be used as a [wildcard](#wildcards). |
Here’s an example using `curl`:
```bash
curl https://api.honeybadger.io/v1/source_maps \
-F api_key=Your project API key \
-F revision=dcc69529edf375c72df39b0e9195d60d59db18ff \
-F minified_url=https://example.com/assets/application.min.js \
-F source_map=@path/to/application.js.map \
-F minified_file=@path/to/application.min.js \
-F http://example.com/assets/application.js=@path/to/application.js \
-F http://example.com/assets/utils.js=@path/to/utils.js
```
## Response codes
[Section titled “Response codes”](#response-codes)
The `/v1/source_maps` API endpoint responds with the following codes:
| Code | Status | Description |
| ----- | ------------ | ---------------------------------------------------------------------------------------------------------------------- |
| `201` | Created | The files were uploaded successfully. |
| `400` | Bad Request | You’re missing a required parameter or have exceeded the maximum file size of 80MB per file (check the error message). |
| `401` | Unauthorized | Your API key is invalid. |
## Wildcards
[Section titled “Wildcards”](#wildcards)
In some cases you may want to upload the same source map for different URLs—for instance, if you serve your files from multiple subdomains, or via both HTTP and HTTPS.
An asterisk (`*`) can be used in URLs to perform a wildcard match. For example, the following example will match both the `http://` and
`https://` version of the URL:
```plaintext
http*://example.com/assets/application.min.js
```
…matches the following URLs:
```plaintext
http://example.com/assets/application.min.js
https://example.com/assets/application.min.js
```
Wildcards are *not* supported in file names:
```plaintext
// invalid (will be an exact match):
https://example.com/assets/*.min.js
```
# Status pages API reference
> API reference for managing status pages with endpoints to create, read, update, and delete resources.
Create and manage status pages within your accounts.
## Get all status pages
[Section titled “Get all status pages”](#get-all-status-pages)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/ACCOUNT_ID/status_pages
```
Returns a list of all status pages in this account.
```json
{
"results": [
{
"id": "rMGSZB",
"name": "My Awesome Status Page",
"account_id": "Me3upk",
"domain": "your.custom.domain",
"url": "your.custom.domain",
"created_at": "2022-01-29T11:26:19.120153Z",
"domain_verified_at": "2022-01-29T14:02:32.570227Z",
"sites": [],
"check_ins": [
{
"check_in_id": "XXXXXX",
"display_name": "Nightly billing",
"state": "reporting",
"reported_at": "2022-01-29T00:00:02.523254Z"
}
]
},
{
"id": "vWbSWr",
"name": "Really Awesome Status Page",
"account_id": "Me3upk",
"domain": null,
"url": "vWbSWr.status.hbuptime.com",
"created_at": "2022-01-29T11:09:32.570227Z",
"domain_verified_at": null,
"sites": [
{
"site_id": "7d25f58b-d1a9-49f1-b10a-ac7ee44a6537",
"display_name": "Main site",
"state": "up",
"last_checked_at": "2022-01-29T11:09:30.982801Z"
},
{
"site_id": "7d25f58b-d1a9-49f1-b10a-ac7ee44a6557",
"display_name": "API",
"state": "up",
"last_checked_at": "2022-01-29T11:04:28.675309Z"
}
],
"check_ins": []
}
],
"links": {
"self": "http://localhost:3000/v2/accounts/4bYurk/status_pages"
}
}
```
## Get a single status page’s details
[Section titled “Get a single status page’s details”](#get-a-single-status-pages-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/accounts/ACCOUNT_ID/status_pages/ID
```
```json
{
"id": "vWbSWr",
"name": "Really Awesome Status Page",
"account_id": "Me3upk",
"domain": null,
"url": "vWbSWr.status.hbuptime.com",
"created_at": "2022-01-29T11:09:32.570227Z",
"domain_verified_at": null,
"sites": [
{
"site_id": "7d25f58b-d1a9-49f1-b10a-ac7ee44a6537",
"display_name": "Main site",
"state": "up",
"last_checked_at": "2022-01-29T11:09:30.982801Z"
},
{
"site_id": "7d25f58b-d1a9-49f1-b10a-ac7ee44a6557",
"display_name": "API",
"state": "up",
"last_checked_at": "2022-01-29T11:04:28.675309Z"
}
],
"check_ins": []
}
```
## Create a status page
[Section titled “Create a status page”](#create-a-status-page)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' \
-d '{
"status_page": {
"name": "Really Awesome Status Page",
"domain": "your.custom.domain",
"sites": [
{
"site_id": "7d25f58b-d1a9-49f1-b10a-ac7ee44a6537",
"display_name": "Main site"
}
]
}
}' https://app.honeybadger.io/v2/accounts/ACCOUNT_ID/status_pages
```
You can specify these fields within the `status page` object:
| Field name | Type | Description |
| --------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | string | The name of the status page |
| `domain` | string | (Optional) A custom domain for the status page. Setting this will trigger the domain DNS verification check. |
| `sites` | object\[] | (Optional) Details of sites to add to this status page. Each object references a site in a project in this account, and must contain the `site_id` and an optional `display_name` and `position`. The `position` field is a zero-indexed integer that controls how your sites will be ordered on the status page. |
| `check_ins` | object\[] | (Optional) Details of check-ins to add to this status page. Each object references a check-in in a project in this account, and must contain the `check_in_id` and an optional `display_name` and `position`. The `position` field is a zero-indexed integer that controls how your check-ins will be ordered on the status page. |
| `hide_branding` | boolean | Whether or not to hide the Honeybadger branding in the footer of the status page. Only available on the Team plan and above. |
| features | object | Additional customization options only available on the Team plan and above. Available options:- `home_link`: URL to hyperlink the status page title or logo to.
- `up_caption`: The caption displayed when all checks are passing.
- `down_caption`: The caption displayed when all checks are failing.
- `mixed_caption`: The caption displayed when some checks are failing.
- `custom_css`: Custom CSS that will be injected into the status page. |
Returns a 201 Created response containing the created status page’s details.
## Update a status page
[Section titled “Update a status page”](#update-a-status-page)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' \
-d '{
"status_page": {
"domain": "different.custom.domain",
"sites": [
{
"site_id": "7d25f58b-d1a9-49f1-b10a-ac7ee44a6537",
"display_name": "Main site"
}
]
}
}' https://app.honeybadger.io/v2/accounts/ACCOUNT_ID/status_pages/ID
```
You can specify one or more of these fields within the `status page` object:
| Field name | Type | Description |
| --------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | string | The name of the status page |
| `domain` | string | A custom domain for the status page. Changing this will trigger the domain DNS verification check. |
| `sites` | object\[] | Details of sites to add to this status page. Each object references a site in a project in this account, and must contain the `site_id` and an optional `display_name`. |
| `hide_branding` | boolean | Whether or not to hide the Honeybadger branding in the footer of the status page. Only available on the Team plan and above. |
| `features` | object | Additional customization options only available on the Team plan and above. Available options:- `home_link`: URL to hyperlink the status page title or logo to.
- `up_caption`: The caption displayed when all checks are passing.
- `down_caption`: The caption displayed when all checks are failing.
- `mixed_caption`: The caption displayed when some checks are failing.
- `custom_css`: Custom CSS that will be injected into the status page. |
Returns an empty response (204 No Content) if successful.
## Delete a status page
[Section titled “Delete a status page”](#delete-a-status-page)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/accounts/ACCOUNT_ID/status_pages/ID
```
Returns an empty response (204 No Content) if successful.
# Streams API reference
> API reference for listing Insights streams and retrieving their IDs for use in queries and alarms.
Insights events live in streams. Every project has two built-in streams: `default`, which receives events sent by your applications, and `internal`, which receives Honeybadger-generated events such as error occurrences, deployments, uptime checks, and check-ins.
Use stream IDs in the `stream_ids` request field to choose which streams [Insights queries](/api/insights/) and [alarms](/api/alarms/) search.
## Get all streams
[Section titled “Get all streams”](#get-all-streams)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/streams
```
Returns a list of the project’s streams.
```json
{
"results": [
{
"id": "a1b2c3d4e5f6",
"name": "Default",
"slug": "default",
"internal": false,
"project_id": 1,
"created_at": "2026-07-15T13:56:29.513358Z"
},
{
"id": "f6e5d4c3b2a1",
"name": "Internal",
"slug": "internal",
"internal": true,
"project_id": 1,
"created_at": "2026-07-15T13:56:29.513358Z"
}
],
"links": {
"self": "https://app.honeybadger.io/v2/projects/1/streams"
}
}
```
| Field name | Type | Description |
| ------------ | ------- | ------------------------------------------------------------------------------------------------------ |
| `id` | string | The stream ID accepted by the `stream_ids` request field in Insights queries and alarms. |
| `name` | string | The stream’s display name. |
| `slug` | string | The stable identifier for the stream’s role: `default` or `internal`. |
| `internal` | boolean | Whether the stream holds Honeybadger-generated events (`notice`, `deploy`, `uptime_check`, and so on). |
| `project_id` | integer | The project the stream belongs to. |
| `created_at` | string | The ISO 8601 timestamp when the stream was created. |
Streams also appear in the `streams` array of [project payloads](/api/projects/).
## Notes
[Section titled “Notes”](#notes)
* Stream selection is per-project. IDs that don’t belong to the project (whether unknown or from another project) are silently ignored. A request containing those IDs may therefore return fewer results than expected instead of an error.
* Streams are provisioned asynchronously after project creation, so a just-created project’s stream list may be empty or partial for a short time. Retry the request before concluding that streams are missing.
# Teams API reference
> API reference for managing teams with endpoints to retrieve and update team members and permissions.
## Get a team list or team details
[Section titled “Get a team list or team details”](#get-a-team-list-or-team-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/teams?account_id=ACCOUNT_ID
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/teams/ID
```
Returns a list of teams
```json
{
"id": 1,
"name": "The Avengers",
"created_at": "2013-01-11T15:40:35Z",
"owner": {
"id": 1,
"email": "thor@example.org",
"name": "Thor"
},
"members": [...],
"projects": [...],
"invitations": [...]
}
```
If the `account_id` parameter is not supplied when requesting the list of teams, all teams will be returned across all accounts to which the provided AUTH\_TOKEN has access.
## Create a team
[Section titled “Create a team”](#create-a-team)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' -d '{"team":{"name":"My team"}}' https://app.honeybadger.io/v2/teams?account_id=ACCOUNT_ID
```
You can specify these fields:
| Field name | Type | Description |
| ---------- | ------ | ----------- |
| `name` | string | |
If the `account_id` query parameter is not provided, the team will be associated with the first account accessible by the user associated with the AUTH\_TOKEN.
## Update a team
[Section titled “Update a team”](#update-a-team)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"team":{"name":"Updated team name"}}' https://app.honeybadger.io/v2/teams/ID
```
## Delete a team
[Section titled “Delete a team”](#delete-a-team)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/teams/ID
```
## Get a list of team members or team member details
[Section titled “Get a list of team members or team member details”](#get-a-list-of-team-members-or-team-member-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/teams/ID/team_members
```
Returns all the members or a single team member for the given team:
```json
{
"id": 1,
"created_at": "2012-12-13T15:00:47Z",
"admin": true,
"name": "",
"email": "westley@example.com"
}
```
## Update a team member
[Section titled “Update a team member”](#update-a-team-member)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"team_member":{"admin":true}}' https://app.honeybadger.io/v2/teams/ID/team_members/ID
```
The list of valid fields is as follows:
| Field name | Type | Description |
| ---------- | ------- | ----------- |
| `admin` | boolean | |
## Delete a team member
[Section titled “Delete a team member”](#delete-a-team-member)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/teams/ID/team_members/ID
```
## Create a team invitation
[Section titled “Create a team invitation”](#create-a-team-invitation)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' \
-d '{"team_invitation":{"email":"inigo@example.com"}}' \
https://app.honeybadger.io/v2/teams/ID/team_invitations
```
You can specify these fields:
| Field name | Type | Description |
| ---------- | ------- | ------------------------------------------------------------------ |
| `email` | string | The invited user’s email address. |
| `admin` | boolean | (Optional) Set this to true to make the invited user a team admin. |
| `message` | string | (Optional) The message to be included in the invitation email. |
Returns the created team invitation:
```json
{
"id": 9,
"email": "inigo@example.com",
"created_by": {
"email": "westley@example.com",
"name": "Westley"
},
"accepted_by": null,
"admin": false,
"accepted_at": null,
"created_at": "2013-01-08T15:42:16Z",
"message": null
}
```
## Update a team invitation
[Section titled “Update a team invitation”](#update-a-team-invitation)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' \
-d '{"team_invitation":{"admin": true}}' \
https://app.honeybadger.io/v2/teams/ID/team_invitations/ID
```
You can specify either of these fields:
| Field name | Type | Description |
| ---------- | ------- | ------------------------------------------------------- |
| `admin` | boolean | Set this to true to make the invited user a team admin. |
| `message` | string | The message to be included in the invitation email. |
## Get a team invitation list or team invitation details
[Section titled “Get a team invitation list or team invitation details”](#get-a-team-invitation-list-or-team-invitation-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/teams/ID/team_invitations
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/teams/ID/team_invitations/ID
```
Returns a list of team invitations or a single team invitation for the given team:
```json
{
"id": 9,
"email": "inigo@example.com",
"created_by": {
"email": "westley@example.com",
"name": "Westley"
},
"accepted_by": {
"email": "inigo@example.com",
"name": "Inigo Montoya"
},
"admin": true,
"accepted_at": "2013-01-08T15:42:41Z",
"created_at": "2013-01-08T15:42:16Z",
"message": null
}
```
## Delete a team invitation
[Section titled “Delete a team invitation”](#delete-a-team-invitation)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/teams/ID/team_invitations/ID
```
# Uptime API reference
> API reference for managing uptime monitors with endpoints to create, read, update, and delete resources.
## Get a site list or site details
[Section titled “Get a site list or site details”](#get-a-site-list-or-site-details)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/sites
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/sites/ID
```
Returns a list of sites or a single sites for the given project with the following format:
```json
{
"active": true,
"frequency": 5,
"id": "9eed6a7e-af77-4cc6-8c55-b7b17555330d",
"last_checked_at": "2016-06-15T12:57:29.646956Z",
"match": null,
"match_type": "success",
"name": "Main site",
"state": "down",
"url": "http://www.example.com"
}
```
## Create a site
[Section titled “Create a site”](#create-a-site)
```bash
curl -u AUTH_TOKEN: -X POST -H 'Content-type: application/json' -d '{"site":{"name":"My site","url":"https://www.example.com/"}}' https://app.honeybadger.io/v2/projects/ID/sites
```
Here is a list of the fields that can be specified:
| Field name | Type | Description |
| ----------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `name` | string | |
| `url` | string | |
| `frequency` | integer | Number of minutes between checks (valid values are 1, 5, or 15). |
| `match` | string | The status code that will be returned or string to be present/absent to indicate a passing check, depending on the value of `match_type`. Unused when the match\_type is “success”. |
| `match_type` | string | One of “success” for a status code of 200-299, “exact” for a particular status code (provided via the `match` field), “include” to require the text in `match` to be present on the page, and “exclude” to require the text in `match` to not be present on the page. |
| `request_method` | string | One of GET, POST, PUT, PATCH, or DELETE. |
| `request_body` | string | The body content to be sent with the check. |
| `request_headers` | array | Array of hashes (e.g., `[{ key: "Content-type", value: "application/json" }]`) that will be added to the request headers. |
| `locations` | array | Array of strings (e.g, `['London', 'Virginia']`) that will limit the locations that will be used for the checks. Providing an empty array (the default) will cause all locations to be used. Available locations are Virginia, Oregon, Frankfurt, Singapore, and London. |
| `validate_ssl` | boolean | Whether to have the check fail if the SSL certificate is not valid or is expired. |
| `timeout` | integer | **Business and Enterprise customers only.** How long the uptime check will wait for a response before reporting the site as down (in seconds). The default is 30 seconds and the maximum is 120 seconds. |
| outage\_threshold | integer | The number of unsuccessful checks required to trigger an alert. If this is blank, then an alert will be sent after half of the locations return with failed checks. |
| `active` | boolean | Whether to run the checks. |
## Update a site
[Section titled “Update a site”](#update-a-site)
```bash
curl -u AUTH_TOKEN: -X PUT -H 'Content-type: application/json' -d '{"site":{"name":"Updated site name"}}' https://app.honeybadger.io/v2/projects/ID/sites/ID
```
Update requests can change the same fields as create requests.
## Delete a site
[Section titled “Delete a site”](#delete-a-site)
```bash
curl -u AUTH_TOKEN: -X DELETE https://app.honeybadger.io/v2/projects/ID/sites/ID
```
## Get a list of outages for a site
[Section titled “Get a list of outages for a site”](#get-a-list-of-outages-for-a-site)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/sites/ID/outages
```
Returns a list of outages with the following format:
```json
{
"down_at": "2015-02-17T18:20:44.776959Z",
"up_at": "2015-02-17T18:22:35.614678Z",
"created_at": "2015-02-17T18:20:44.777914Z",
"status": 301,
"reason": "Expected 2xx status code. Got 301",
"headers": {
"Date": "Tue, 17 Feb 2015 18:20:44 GMT",
"Server": "DNSME HTTP Redirection",
"Location": "http://text.vote/polls",
"Connection": "close",
"Content-Length": "0"
}
}
```
The outage list can be filtered with these URL parameters:
| Parameter | Description |
| ---------------- | ---------------------------------------------------- |
| `created_after` | A Unix timestamp (number of seconds since the epoch) |
| `created_before` | A Unix timestamp (number of seconds since the epoch) |
| `limit` | Number of results to return (max and default are 25) |
The outage list is always ordered by creation time descending.
## Get a list of uptime checks for a site
[Section titled “Get a list of uptime checks for a site”](#get-a-list-of-uptime-checks-for-a-site)
```bash
curl -u AUTH_TOKEN: https://app.honeybadger.io/v2/projects/ID/sites/ID/uptime_checks
```
Returns a list of uptime checks with the following format:
```json
{
"created_at": "2016-06-16T20:19:32.852569Z",
"duration": 1201,
"location": "Singapore",
"up": true
}
```
The uptime check list can be filtered with these URL parameters:
| Parameter | Description |
| ---------------- | ---------------------------------------------------- |
| `created_after` | A Unix timestamp (number of seconds since the epoch) |
| `created_before` | A Unix timestamp (number of seconds since the epoch) |
| `limit` | Number of results to return (max and default are 25) |
The uptime check list is always ordered by creation time descending.
# Accounts
> Manage billing and users.
Accounts are the primary billing entities in Honeybadger. An account is created for you when you first sign up, unless you are signing up as a result of being invited to another user’s account. You can create additional accounts and switch between accounts using the dropdown in the navigation bar.
## Account-wide information
[Section titled “Account-wide information”](#account-wide-information)
Honeybadger can display information from several projects on an account-wide basis, including the following:
* Errors
* Uptime Checks
* Check-Ins
Links to these views are available in the left-hand sidebar. [Status Pages](/guides/status-pages) are also managed at the account level, as they can include uptime checks and check-ins from multiple projects.
## Account settings
[Section titled “Account settings”](#account-settings)
From the account settings page, you can:
* See the current billing subscription
* Edit account options
* Add & remove users
* See past invoices
* Change authentication settings
* Manage the referral program
* Park and delete accounts
To learn more about adding, removing, and editing users currently registered to an account and changing the authentication settings, please check out the [User Management](/guides/user-management) page.
## Billing
[Section titled “Billing”](#billing)
Each account is billed separately based on a chosen subscription plan and has its own payment information. The following changes can be made from the Account Settings page for each account regarding billing:
* Subscription plan
* Payment information
* Business details displayed on invoices
A list of invoices for the account is also available from the Account Settings page.
### Changing the subscription plan
[Section titled “Changing the subscription plan”](#changing-the-subscription-plan)
You can change your subscription plan at any time. When you upgrade, downgrade, or change the payment period for your subscription (switch from monthly to yearly, or vice-versa), your account will be prorated for the difference in cost between the old and new plans. The prorated amount will show up as a credit on your next invoice. When you upgrade to a plan that costs more, the next invoice will be larger than normal, as it will have the prorated charge for the newly-selected plan for the remainder of the current billing period in addition to the full charge for the next billing period.
On the payment information page we provide a link that can be used to update the account’s payment information without having to be logged in to Honeybadger. This can be useful if you are managing the account but don’t have access to a company credit card. Alternatively, you can invite additional account owners via the Users tab, and those individuals will be able to update the payment information once logged in.
Payment via purchase order/invoice is available to subscribers on any of our Business plans when billed annually. Please \[contact support]\(mailto:support\@honeybadger.io?subject=Payment by invoice) to arrange that.
Honeybadger is also available through [AWS Marketplace](/guides/aws-marketplace/), which lets you pay for your subscription through your AWS bill. If you already have a Honeybadger account, we can migrate your data to a new Marketplace-billed account for you.
## Account options
[Section titled “Account options”](#account-options)
From the account options tab, you can change the account name and the billing contact, as well as adjust whether or not overage billing is enabled. The tech contact email, if provided, will receive notifications from Honeybadger for non-billing-related information.
## Referral program
[Section titled “Referral program”](#referral-program)
Honeybadger offers a referral program that lets you earn up to 20% of referred customers’ payments as account credits. These credits can reduce your monthly bill—even down to $0.
To join the program, navigate to the Referrals tab in your account settings, accept the terms, and share your unique referral link. See the [referral program guide](/resources/referral-program) to learn more about the referral program and how to get started.
## Account parking
[Section titled “Account parking”](#account-parking)
If you’d like to suspend billing for a while, but you’d also like to preserve all the projects, users, etc. associated with your account, then you can choose to park your account. Doing so will stop all error processing, uptime checks, and check-in monitoring for the projects associated with your account. Un-parking your account will cause billing and all processing to be resumed.
## Deleting your account
[Section titled “Deleting your account”](#deleting-your-account)
When you choose to delete an account, all the data associated with the account (projects, teams, etc.) will be immediately deleted, and billing will be stopped. There is no undo for this action, so be sure you’re ready before pushing the button!
# AWS Marketplace
> Subscribe to Honeybadger through AWS Marketplace or migrate an existing account to Marketplace billing.
Honeybadger is available through [AWS Marketplace](https://aws.amazon.com/marketplace/), which lets you pay for your subscription through your AWS bill and apply your AWS committed spend toward Honeybadger.
## Subscribing through AWS Marketplace
[Section titled “Subscribing through AWS Marketplace”](#subscribing-through-aws-marketplace)
1. Visit the [Honeybadger listing on AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-yozbmqhcmlrkm) and subscribe to the plan that fits your needs.
2. Complete the AWS Marketplace signup flow. This creates a new Honeybadger account that is billed through AWS.
3. Sign in to your new Honeybadger account to confirm it was provisioned successfully.
If you’re new to Honeybadger, you can start adding projects and team members to your new account right away. If you already have a Honeybadger account that you want to switch to Marketplace billing, see the next section.
## Migrating an existing account to AWS Marketplace
[Section titled “Migrating an existing account to AWS Marketplace”](#migrating-an-existing-account-to-aws-marketplace)
If you already have a Honeybadger account and want to switch to AWS Marketplace billing, we’ll transfer your projects, users, and historical data to the new Marketplace-billed account for you:
1. Subscribe through AWS Marketplace using the steps above. This creates a new, empty Honeybadger account.
2. [Contact support](mailto:support@honeybadger.io?subject=AWS%20Marketplace%20migration) from the email address associated with your existing account and let us know you’d like to migrate. Include the name of your existing account and the name of your new Marketplace account.
3. We’ll transfer your account settings, projects, team members, and historical data from your existing account to your new Marketplace-billed account. Your existing API keys come along with your projects, so your installed libraries and integrations will continue reporting to Honeybadger without any changes on your end.
4. Once the migration is complete and you’ve verified everything looks right in the new account, you can [close your old account](/guides/accounts/#deleting-your-account).
## Managing your subscription
[Section titled “Managing your subscription”](#managing-your-subscription)
Once your account is billed through AWS Marketplace, plan changes, cancellations, and payment method updates are managed through AWS Marketplace rather than the Honeybadger account settings page. Invoices and payment history are available in your AWS account.
# Check-ins
> Get notified when cron jobs and scheduled tasks have errors or don't run on time.
Your Honeybadger account comes with check-ins, a way for the processes running on your servers to report that they are alive. Once configured, should a check-in go missing, Honeybadger will send you an alert to let you know that your process has stopped reporting. This is especially useful for monitoring cron jobs, so you can avoid having a cron job silently fail and go unnoticed.
## Setup
[Section titled “Setup”](#setup)
When you create a check-in, you’ll configure the following options:
### Name
[Section titled “Name”](#name)
A label for your check-in. If not provided, a token identifier will be used.
### Slug
[Section titled “Slug”](#slug)
An optional human-readable identifier that can be used as an alternate check-in URL. See [Slugs](#slugs) below.
### Schedule type
[Section titled “Schedule type”](#schedule-type)
Choose **Simple** to check in at a regular interval, or **Cron** to use a cron expression for advanced scheduling.
#### Simple
[Section titled “Simple”](#simple)
Honeybadger will watch the process at an interval you define.
##### Report period
[Section titled “Report period”](#report-period)
How often you expect the check-in to report (e.g., “1 hour”).
#### Cron
[Section titled “Cron”](#cron)
Cron scheduling allows you to use a cron expression to create an advanced check-in schedule or mirror the cron schedule on your server.
##### Schedule
[Section titled “Schedule”](#schedule)
The cron expression (e.g., `*/5 * * * *`).
##### Time zone
[Section titled “Time zone”](#time-zone)
The time zone of the server where cron is running.
### Grace period
[Section titled “Grace period”](#grace-period)
An optional grace period allows some time for long-running tasks to be completed before Honeybadger sends a notification due to a lack of reporting. For example, if you have a job that reports every hour but can take up to twenty minutes to run, you can specify a grace period of twenty minutes, and Honeybadger will allow up to one hour and twenty minutes to elapse before a notification is sent.
## Reporting
[Section titled “Reporting”](#reporting)
When you create a new check-in, you’ll get a URL that you can use to report that your process is alive. The easiest way to report a check-in is with [the Honeybadger CLI’s `hb check-in` command](/resources/cli/#check-in):
```sh
@hourly /usr/bin/do_something && hb check-in --id XyZZy
```
Or use `curl` to fetch the check-in URL directly:
```sh
@hourly /usr/bin/do_something && curl https://api.honeybadger.io/v1/check_in/XyZZy &> /dev/null
```
See the [API docs](/api/reporting-check-ins/) for more information about the data you can send when reporting a check-in.
You will also get an email address you can use for reporting the status of your process. No subject or body text is required, but the email address *is* case-sensitive:
```sh
@hourly /usr/bin/do_something && echo | mail XyZZy@report.hbchk.in
```
Please note that while these examples use cron, you can trigger check-in reporting from the shell, a scheduled background job, or any other process that can request a URL or send an email.
## Slugs
[Section titled “Slugs”](#slugs)
A slug is an optional, human-readable identifier for a check-in. When you add a slug, you get an alternate check-in URL that uses the slug and a [project API key](/guides/projects/#api-keys) instead of the check-in ID. This is useful if you don’t want to embed check-in IDs in your code or automated systems. For example, if you specify a slug of `hourly-check`, your alternate check-in URL will look like:
```sh
https://api.honeybadger.io/v1/check_in/hbp_ABC/hourly-check
```
You can add a slug when creating a check-in in the UI, via the [REST API](/api/check-ins/#create-a-check-in), or in a config file using our [PHP/Laravel](/lib/php/guides/configuring-checkins/) and [JavaScript](/lib/javascript/guides/check-ins/) client libraries.
## Payloads
[Section titled “Payloads”](#payloads)
You can POST a small payload to the UI that includes the results of the command you ran, including the command’s output, exit code, and duration. Please see our [API documentation](/api/reporting-check-ins/#check-in-payloads) for the format of that payload.
The easiest way to send check-in payloads is to use [the Honeybadger CLI’s `hb run` command](/resources/cli/#run) to wrap your scheduled command:
```shell
hb run --id XyZZy -- /usr/local/bin/backup.sh
```
Or [POST directly to the check-in API](/api/reporting-check-ins/#check-in-payloads) with a JSON payload:
```bash
curl -X POST https://api.honeybadger.io/v1/check_in/XyZZy \
-H "Content-Type: application/json" \
-d '{"check_in": {"status": "success", "duration": 1234, "stdout": "backup completed"}}'
```
You can view the payload data in your check-in history or query it in [Insights](/guides/insights/).
## Notifications
[Section titled “Notifications”](#notifications)
When your check-in goes missing, we’ll notify you with information about which job failed to report on time. You can enable or disable these notifications along with the rest of the notification events in your Personal Alerts or Project Integrations settings.
## Status page integration
[Section titled “Status page integration”](#status-page-integration)
Check out our [Status Pages](/guides/status-pages/#uptime-checks) feature for information on how to present the status your check-ins to your users.
# Dashboards & APM
> Learn how to use dashboards to display widgets created from Insights queries and visualizations.
Dashboards let you collect your most important [Honeybadger Insights](/guides/insights/) charts and data in one place so you can see what’s happening with your app at a glance. Instead of running queries repeatedly or jumping between pages, dashboards give you a single view of your application’s health and performance, helping you spot trends and fix issues.
## Getting started
[Section titled “Getting started”](#getting-started)
To create a dashboard, navigate to the *Dashboards* section in your Honeybadger project, click the dashboard selector in the top left, then click the **+** button next to the dashboard you want to add.
## Project Overview dashboard
[Section titled “Project Overview dashboard”](#project-overview-dashboard)
The [Project Overview dashboard](/guides/dashboards/project-overview/) provides a comprehensive view of your application’s health and performance. It’s automatically added to every new Honeybadger project, giving you immediate visibility into alarms, deployments, errors, uptime checks, and check-ins.
## Automatic dashboards
[Section titled “Automatic dashboards”](#automatic-dashboards)
To help you get started quickly, Honeybadger provides pre-configured automatic dashboards with relevant widgets for common frameworks and platforms. These dashboards are automatically populated when you enable instrumentation for supported platforms.
### Getting started with automatic dashboards
[Section titled “Getting started with automatic dashboards”](#getting-started-with-automatic-dashboards)
To enable automatic dashboards for your applications, follow these steps:
1. Enable Honeybadger Insights instrumentation in your client library (e.g., [Ruby](/lib/ruby/insights/automatic-instrumentation/), [Elixir](/lib/elixir/insights/automatic-instrumentation/), [PHP](/lib/php/insights/automatic-instrumentation/), etc.)
2. Deploy your application with the updated configuration
3. Navigate to the *Dashboards* section in your Honeybadger project, click *Create dashboard*, select the dashboard you want, then click *Add dashboard*.
Your dashboard will begin to populate with data as soon as your application starts sending events to Honeybadger.
## Customizing dashboards
[Section titled “Customizing dashboards”](#customizing-dashboards)
You can customize any dashboard by clicking the **…** menu in the top right corner of the dashboard. From there, you can:
* **Edit** - Modify the dashboard layout and widgets
* **Clone** - Create a copy of the dashboard
* **Set as default dashboard** - Make this dashboard your default view
* **Set default time range** - Configure the default time period
* **Edit source** - View and edit the dashboard’s YAML configuration
* **Delete dashboard** - Remove the dashboard
### Widget library
[Section titled “Widget library”](#widget-library)
When adding new widgets to a dashboard, you can choose from a library of pre-configured widget templates. The widget library includes templates for common data sources such as:
* Error rates and deployments
* Database performance metrics
* Background job processing times
* Request counts and response distributions
* Cache hit rates
To add a widget from the library, click the **+** *Add widget* menu in the top right corner of the dashboard and select a template. You can customize any widget after adding it to your dashboard.
### Editing widgets
[Section titled “Editing widgets”](#editing-widgets)
In edit mode, you can configure any widget by clicking the **…** menu on the widget and selecting **Edit widget**. This opens the widget editor where you can modify the query, change the visualization type, and preview results before saving.
### Parameterized queries
[Section titled “Parameterized queries”](#parameterized-queries)
You can make dashboard widgets dynamic by using parameters in your queries. Parameters let you create reusable dashboards where values can be changed via the URL or the **Parameters** button in the dashboard toolbar, without editing the widget configuration. For example, a single dashboard can be filtered to one host, environment, or customer at a time — and shared as a prefilled link.
#### Adding a parameter to a widget
[Section titled “Adding a parameter to a widget”](#adding-a-parameter-to-a-widget)
To add a parameter to a dashboard widget:
1. Open the dashboard and click **Edit**.
2. Click the **…** menu on the widget and choose **Edit widget**.
3. Add a reference like `${hostname}` anywhere in the widget’s query — for example, `filter hostname::str == "${hostname}"`.
4. When the editor prompts you, provide a value for the new parameter so the preview can render. Click **Update** to save the widget.
Once a parameter is defined, any widget on the dashboard that uses the same name will share the same value. To apply one parameter across several widgets, reference it from each widget’s query — either through the widget editor or by [editing the dashboard source](#editing-dashboard-source).
#### Setting parameter values
[Section titled “Setting parameter values”](#setting-parameter-values)
There are three ways to set parameter values on a dashboard:
1. **URL parameters** — Add parameters directly to the URL (e.g., `?hostname=web-01`). Because parameters are URL-based, you can bookmark or share a link that already has the values filled in.
2. **Parameters popover** — Click the **Parameters** button (the slider icon in the dashboard toolbar, next to the date picker) to open a popover with a field for each parameter used on the dashboard. Enter values and click **Apply**, or click **Reset to defaults** to restore default values.
3. **From widget results** — Click a field value in a widget’s results. If the field name matches a parameter used on the dashboard, you’ll see a “set parameter” option that updates every widget using that parameter.
#### Default values
[Section titled “Default values”](#default-values)
Giving a parameter a default with `${name:-default}` means the widget can render even when no value has been supplied. Defaults are useful for:
* Setting a sensible baseline (e.g., `${env:-production}`) that viewers can override.
* Ensuring a dashboard renders on first load before anyone has edited parameters.
#### Parameters required state
[Section titled “Parameters required state”](#parameters-required-state)
When a widget references a parameter that has no default and no value has been supplied via the URL or the parameters popover, the widget displays a **Parameters required** message with an **Edit parameters** button. The **Parameters** button in the dashboard toolbar also shows an indicator dot, signaling that one or more values need to be set. Click either to open the parameters popover and supply the missing values.
### Editing dashboard source
[Section titled “Editing dashboard source”](#editing-dashboard-source)
For advanced customization, select **Edit source** to view and modify the entire dashboard configuration as YAML. This is useful for:
* Making bulk changes without navigating the UI
* Copying dashboards between projects
* Sharing configurations with team members
The editor validates your configuration against a predefined schema and displays helpful error messages if something’s wrong. Stream IDs are automatically converted to human-readable names, so you don’t need to manually update identifiers when moving configurations between projects.
## Available dashboards
[Section titled “Available dashboards”](#available-dashboards)
[Project Overview](/guides/dashboards/project-overview/)Deployments, errors, uptime, check-ins, and performance at a glance
[Active Job](/guides/dashboards/active-job/)Job counts, durations, and failure rates by job class
[Active Job Metrics](/guides/dashboards/active-job-metrics/)Pre-aggregated job throughput, durations, and stats by job class
[Autotuner](/guides/dashboards/autotuner/)Heap growth, GC counts, and memory tuning suggestions
[Celery](/guides/dashboards/celery/)Task counts by status, average durations, failures and retries
[Django](/guides/dashboards/django/)Request durations, response status counts, slowest views and queries
[Flask](/guides/dashboards/flask/)Request durations, response codes, and slowest views and queries by blueprint
[Heroku](/guides/dashboards/heroku/)Router status codes, Postgres load averages, and slowest paths
[Karafka](/guides/dashboards/karafka/)Consumer lag, processing durations, and broker errors by topic
[Laravel](/guides/dashboards/laravel/)Request and job durations, response distributions, slowest controllers and queries
[Net::HTTP Metrics](/guides/dashboards/net-http-metrics/)Outbound HTTP throughput, durations, and status codes by host
[Oban](/guides/dashboards/oban/)Job counts by status, durations by worker, and slowest job runs
[Phoenix](/guides/dashboards/phoenix/)Request stats, slowest controllers and Ecto queries, LiveView event performance
[Puma](/guides/dashboards/puma/)Request backlog, running threads, and pool capacity over time
[Rails](/guides/dashboards/rails/)Slow requests, queries, and partials; cache hit rates by controller
[Rails Metrics](/guides/dashboards/rails-metrics/)Pre-aggregated throughput, controller durations, and DB/view timings
[Sidekiq](/guides/dashboards/sidekiq/)Job counts, durations, and failure rates by worker
[Sidekiq Metrics](/guides/dashboards/sidekiq-metrics/)Pre-aggregated job durations, queue depth, latency, and capacity
[Solid Queue Metrics](/guides/dashboards/solid-queue-metrics/)Job statuses, active workers and dispatchers, and queue depths
[System](/guides/dashboards/system/)CPU load averages, memory usage, and disk usage by device
## Next steps
[Section titled “Next steps”](#next-steps)
* Learn more about [Honeybadger Insights](/guides/insights/)
* Try [BadgerQL](/guides/insights/badgerql/) to explore your data and create custom dashboard widgets
* Set up [Insights Alarms](/guides/insights/alarms/) to turn your queries into actionable alerts
* Send additional data from your [infrastructure](/guides/insights/#adding-data-from-other-sources) to Honeybadger
# Active Job dashboard
> Job counts, durations, and failure rates by job class
Note
Requires the `honeybadger` gem `>= 6.3`.
Drop in Dashboard for your ActiveJob instrumentation data
Works with Solid Queue, GoodJob, and other ActiveJob backends.
**This dashboard includes:**
* Job counts over time by job class
* Average job duration by job class over time
* Job duration distribution (binned by 100ms, by job class)
* Job status counts (success/failure) by job class
* Aggregate job stats: successes, failures, total and average execution time
* 10 slowest job runs (with details)
To get started, make sure you have updated your Honeybadger gem to `>= 6.3`, then enable Insights instrumentation by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Active Job Metrics dashboard
> Pre-aggregated job throughput, durations, and stats by job class
Note
Requires the `honeybadger` gem `>= 6.3`.
Drop in Dashboard for your ActiveJob metrics data
This is the metrics-based counterpart to the ActiveJob (events) dashboard. Works with Solid Queue, GoodJob, and other ActiveJob backends.
**This dashboard includes:**
* Job throughput over time by job class
* Job durations over time by job class
* Job stats with min, max, avg durations
To get started, make sure you have updated your Honeybadger gem to `>= 6.3`, then enable Insights metrics by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
rails:
insights:
metrics: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Autotuner dashboard
> Heap growth, GC counts, and memory tuning suggestions
Note
Requires the `honeybadger` gem `>= 5.26`.
Drop in Dashboard for your Autotuner stats and reports
**This dashboard includes:**
* Heap Pages over time
* Request Time over time
* Garbage Collection Count over time
* Autotuner Report suggestions
To get started, make sure you have updated your Honeybadger gem to `>= 5.26`, then enable Insights instrumentation by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Celery dashboard
> Task counts by status, average durations, failures and retries
Note
Requires the `honeybadger` package `>= 1.1.0`.
Drop in Dashboard for your Celery instrumentation data
**This dashboard includes:**
* Task counts over time by status (SUCCESS, FAILURE, etc.)
* Average task durations across all tasks
* Overall task counts & average durations per task
* Top 10 slowest task runs
* Breakdown of failures, retries & other statuses
* Total successful job count
To get started, make sure you have updated Honeybadger to version 1.1.0 or later.
```yaml
pip install --upgrade honeybadger
```
And enable Insights instrumentation by including this in your config:
```py
celery.conf.update(
HONEYBADGER_INSIGHTS_ENABLED = True,
)
```
# Django dashboard
> Request durations, response status counts, slowest views and queries
Note
Requires the `honeybadger` package `>= 1.1.0`.
Drop in Dashboard for your Django instrumentation data
**This dashboard includes:**
* Request duration distributions (binned by 100 ms)
* Response counts over time, grouped by status codes (2XX, 3XX, 4XX, 5XX)
* Average response durations by view
* Average response durations by app
* Total request counts over time
* Slowest views (avg/max durations and Apdex)
* Top 10 slowest database queries
To get started, make sure you have updated Honeybadger to version 1.1.0 or later.
```yaml
pip install --upgrade honeybadger
```
And enable Insights instrumentation by including this in your config:
```py
HONEYBADGER = {
'INSIGHTS_ENABLED': True,
}
```
# Flask dashboard
> Request durations, response codes, and slowest views and queries by blueprint
Note
Requires the `honeybadger` package `>= 1.1.0`.
Ready-made dashboard for monitoring Flask applications
**This dashboard includes:**
* Average response durations by view
* Average response durations by blueprint
* Response counts over time, grouped by status codes (2XX, 3XX, 4XX, 5XX)
* Total request count over time
* Top 10 slowest views (avg/max durations and Apdex)
* Request duration distribution histogram (binned by 100 ms)
* Top 10 slowest database queries
To get started, make sure you have updated Honeybadger to version 1.1.0 or later.
```yaml
pip install --upgrade honeybadger
```
And enable Insights instrumentation by including this in your config:
```py
class Config:
HONEYBADGER_INSIGHTS_ENABLED = True
```
# Heroku dashboard
> Router status codes, Postgres load averages, and slowest paths
Ready made dashboard for monitoring Heroku apps. All that is required is to set up your [Heroku log drain](https://docs.honeybadger.io/guides/insights/integrations/heroku/).
**This dashboard includes:**
* Router response status code groupings
* Postgres load averages (1m, 5m, 15m interval samples)
* Query response time percentiles (50, 90, 99 percentiles)
* Top 10 avg slowest response times by path
# Karafka dashboard
> Consumer lag, processing durations, and broker errors by topic
Note
Requires the `honeybadger` gem `>= 5.26`.
Drop in Dashboard for your Karafka instrumentation data
**This dashboard includes:**
* Average Consumer Duration
* Average Consumer Lag
* Number of Messages Processed by Topic
* Average Consumer Consumption and Processing Duration
* Broker Latency
* Broker Errors
To get started, make sure you have updated your Honeybadger gem to `>= 5.26`, then enable Insights instrumentation and Karafka metrics by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
karafka:
insights:
metrics: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Laravel dashboard
> Request and job durations, response distributions, slowest controllers and queries
Note
Requires the `honeybadger-laravel` package `>= 4.2.0`.
Drop in Dashboard for your Laravel instrumentation data
**This dashboard includes:**
* Total requests over time
* Response distributions binned by 100ms
* Job durations over time
* Slowest controllers w/ Apdex score
* Overall slowest requests
* Slowest overall queries & slowest queries per request
* Slowest external requests
To get started, make sure you have updated your honeybadger-laravel package to `>= 4.2.0 `, then enable Insights instrumentation by including this in your `config/honeybadger.php`:
```php
'events' => [
'enabled' => true
]
```
# Net::HTTP Metrics dashboard
> Outbound HTTP throughput, durations, and status codes by host
Note
Requires the `honeybadger` gem `>= 5.11`.
Drop in Dashboard for your Net::HTTP metrics data
Monitor outbound HTTP requests made via Ruby’s Net::HTTP library, including request durations, throughput, and response status breakdowns by host.
**This dashboard includes:**
* Request throughput by host
* Avg request duration by host
* Responses grouped by status code
* Request duration by HTTP method
* Slowest hosts
To get started, make sure you have updated your Honeybadger gem to `>= 5.11`, then enable Insights metrics by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
net_http:
insights:
metrics: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Oban dashboard
> Job counts by status, durations by worker, and slowest job runs
Note
Requires the `honeybadger` package `>= 0.24`.
Ready made dashboard for your Oban data.
This dashboard includes:
* Overall Job counts by status
* Histogram of job counts by status
* Job durations by Worker module
* Overall Worker stats
* Slowest 10 job runs
To get started, make sure you have updated Honeybadger Elixir Client to `>= 0.24`, then enable Insights instrumentation by including this in your config:
```elixir
config :honeybadger,
insights_enabled: true
```
Check out the Honeybadger client documentation for more information.
# Phoenix dashboard
> Request stats, slowest controllers and Ecto queries, LiveView event performance
Note
Requires the `honeybadger` package `>= 0.24`.
Ready made dashboard for your Phoenix data.
This dashboard includes:
* Request Stats
* Response Counts by status code
* 10 Slowest Controller Actions
* 10 Slowest Ecto Queries
* LiveView Event Performance
* LiveView Mount Performance
* LiveView Event Counts
To get started, make sure you have updated Honeybadger Elixir Client to `>= 0.24`, then enable Insights instrumentation by including this in your config:
```elixir
config :honeybadger,
insights_enabled: true
```
Check out the Honeybadger client documentation for more information.
# Project Overview dashboard
> Monitor application health with the Project Overview dashboard, featuring alarms, deployments, errors, uptime checks, check-ins, and performance metrics.
The Project Overview dashboard provides a comprehensive view of your application’s health and is automatically added to every new Honeybadger project.
**This dashboard includes:**
* Alarms: Triggered and active alarms with recent check status
* Deployments: Recent deployment activity
* Errors: Top errors affecting your application
* Uptime: Monitor status and response times
* Check-ins: Health check status for critical services
* Dynamic widgets (these may vary for your application):
* Slowest Controller Actions: Performance bottlenecks
* Response Status Codes: HTTP response trends
* Database Query Performance: Query execution metrics
# Puma dashboard
> Request backlog, running threads, and pool capacity over time
Note
Requires the `honeybadger` gem `>= 5.26`.
Drop in Dashboard for your Puma instrumentation data
**This dashboard includes:**
* Total requests over time
* Backlog over time
* Running threads over time
* Pool capacity over time
To get started, make sure you have updated your Honeybadger gem to `>= 5.26`, then enable Insights instrumentation by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Rails dashboard
> Slow requests, queries, and partials; cache hit rates by controller
Note
Requires the `honeybadger` gem `>= 5.11`.
Drop in Dashboard for your Rails instrumentation data
**This dashboard includes:**
* Total requests over time
* Response distributions binned by 100ms
* Controller durations & slowest controller actions
* Slowest queries & slowest queries per request
* Slowest partials
* Cache hit rates
To get started, make sure you have updated your Honeybadger gem to `>= 5.11`, then enable Insights instrumentation by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Rails Metrics dashboard
> Pre-aggregated throughput, controller durations, and DB/view timings
Note
Requires the `honeybadger` gem `>= 5.11`.
Drop in Dashboard for your Rails metrics data
This is the metrics-based counterpart to the Rails (events) dashboard. Use this if you’ve enabled metrics without events, or if you prefer pre-aggregated metric data.
**This dashboard includes:**
* Request throughput over time
* Controller durations (weighted average)
* Responses grouped by status code
* Slowest controller actions
* DB & View runtime breakdown
* SQL query durations
* Cache operation durations
To get started, make sure you have updated your Honeybadger gem to `>= 5.11`, then enable Insights metrics by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
rails:
insights:
metrics: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Sidekiq dashboard
> Job counts, durations, and failure rates by worker
Note
Requires the `honeybadger` gem `>= 5.11`.
Drop in Dashboard for your Sidekiq instrumentation data
**This dashboard includes:**
* Job counts over time by worker
* Average job duration by worker over time
* Job duration distribution (binned by 100ms, by worker)
* Job status counts (success/failure) by worker
* Aggregate worker stats: successes, failures, total and average execution time
* 10 slowest job runs (with details)
To get started, make sure you have updated your Honeybadger gem to `>= 5.11`, then enable Insights instrumentation by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Sidekiq Metrics dashboard
> Pre-aggregated job durations, queue depth, latency, and capacity
Note
Requires the `honeybadger` gem `>= 5.11`.
Drop in Dashboard for your Sidekiq metrics data
This is the metrics-based counterpart to the Sidekiq (events) dashboard. In addition to job performance data, this dashboard includes infrastructure metrics like queue depth, latency, capacity, and utilization that are unique to the metrics pipeline.
**This dashboard includes:**
* Job durations by worker over time
* Queue latency and depth per queue
* Capacity and utilization
* Infrastructure stats (processed, failed, scheduled, retry, dead)
To get started, make sure you have updated your Honeybadger gem to `>= 5.11`, then enable Insights metrics by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
sidekiq:
insights:
metrics: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# Solid Queue Metrics dashboard
> Job statuses, active workers and dispatchers, and queue depths
Note
Requires the `honeybadger` gem `>= 6.3`.
Drop in Dashboard for your Solid Queue metrics data
Monitor your Solid Queue infrastructure including job counts, worker/dispatcher status, and queue depths.
**This dashboard includes:**
* Job status overview (in progress, blocked, failed, scheduled, processed)
* Active workers and dispatchers
* Job trends over time
* Queue depths by queue
To get started, make sure you have updated your Honeybadger gem to `>= 6.3`, then enable Insights metrics by including this in your `config/honeybadger.yml`:
```yaml
insights:
enabled: true
solid_queue:
insights:
metrics: true
```
Check out the [Honeybadger client documentation](https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/) for more information.
# System dashboard
> CPU load averages, memory usage, and disk usage by device
Ready made dashboard for monitoring system resources reported by the [Honeybadger CLI agent](https://docs.honeybadger.io/resources/cli/#agent).
**This dashboard includes:**
* CPU load averages (1, 5, and 15 minute intervals)
* Memory usage percentage
* Disk usage percentage by device
# Deployments
> Viewing and tracking deployments.
Deployment tracking lets you record when your app is deployed, see a history of deployments, and correlate code changes with errors. When you deploy, Honeybadger can automatically resolve open errors and notify your team.
## The Deployments page
[Section titled “The Deployments page”](#the-deployments-page)
Your most recent deployments are listed on your project’s Deployments page, sorted by timestamp with the newest first. You can also filter by environment and adjust the time range, with presets for month to date, the last seven days, and yesterday.
For each deployment, Honeybadger displays the timestamp, environment, deploying user, and revision. When GitHub or GitLab is connected, Honeybadger links the revision to a comparison page that shows a diff of what changed since the last deploy.
If your app is on Heroku, the user field shows which Heroku component triggered the deployment.
## Auto-resolving errors on deploy
[Section titled “Auto-resolving errors on deploy”](#auto-resolving-errors-on-deploy)
By default, all [unresolved errors](/guides/errors/#resolve--unresolve) are automatically marked as resolved when a deployment is recorded, which helps keep your [error list](/guides/errors/#browsing-errors) clean. If a resolved error re-occurs after a deploy, you will receive a new notification to let you know the error is still happening.
Auto-resolving assumes you fix errors between deploys (or at least want to be reminded about errors frequently). To disable auto-resolve, uncheck *Resolve errors on deploy* in your [project’s settings](/guides/projects/#resolve-errors-on-deploy).
When disabled, you can still [mark individual errors to resolve on the next deploy](/guides/errors/#resolve-on-deploy) on the error page.
## Searching with deployments
[Section titled “Searching with deployments”](#searching-with-deployments)
Honeybadger’s [error search](/guides/errors/search/) supports several deployment-related tokens:
| Token | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------ |
| `occurred.after:'last deploy'` | Errors that occurred since the most recent deployment |
| `revision:"v1.0"` | Errors that occurred from a deployment with this revision |
| `is:pending_resolution` | Errors set to resolve on the next deploy (when [auto-resolve](#auto-resolving-errors-on-deploy) is disabled) |
The `occurred.after:'last deploy'` token is useful for spotting errors in new code, especially when combined with [environment or assignee filters](/guides/errors/search/#examples).
## Reporting deployments
[Section titled “Reporting deployments”](#reporting-deployments)
To track your deployments, you’ll need to notify Honeybadger each time you deploy. There are several ways to do this depending on your stack:
### Client libraries
[Section titled “Client libraries”](#client-libraries)
We have language-specific deployment tracking guides for [Ruby](/lib/ruby/errors/tracking-deployments/), [JavaScript](/lib/javascript/errors/tracking-deploys/), [PHP](/lib/php/errors/tracking-deploys/), [Python](/lib/python/errors/tracking-deployments/), and [Elixir](/lib/elixir/errors/tracking-deployments/).
### CI/CD and platform integrations
[Section titled “CI/CD and platform integrations”](#cicd-and-platform-integrations)
* **GitHub Actions**: Use the [Honeybadger Deploy Action](https://github.com/marketplace/actions/honeybadger-deploy-action)
* **Heroku**: See the [Heroku guide](/guides/heroku/#heroku-deployment-tracking)
* **Netlify**: See the [JavaScript guide](/lib/javascript/errors/tracking-deploys/#from-netlify)
* **Laravel Forge**: See the [PHP guide](/lib/php/errors/tracking-deploys/#tracking-deploys-from-laravel-forge)
* **DeployHQ**: [Native Honeybadger integration](https://www.deployhq.com/support/integrations/honeybadger)
### Direct API
[Section titled “Direct API”](#direct-api)
For any other tool or pipeline, make a request directly to the Honeybadger API. See the [API reference](/api/reporting-deployments/) for a full list of parameters.
```sh
HONEYBADGER_ENV="production" \
HONEYBADGER_REVISION="$(git rev-parse HEAD)" \
HONEYBADGER_REPOSITORY="$(git config --get remote.origin.url)" \
HONEYBADGER_API_KEY="Your project API key" \
&& curl -g "https://api.honeybadger.io/v1/deploys?deploy[environment]=$HONEYBADGER_ENV&deploy[local_username]=$USER&deploy[revision]=$HONEYBADGER_REVISION&deploy[repository]=$HONEYBADGER_REPOSITORY&api_key=$HONEYBADGER_API_KEY"
```
If you are using our [EU stack](/resources/data-residency/), use `eu-api.honeybadger.io` instead of `api.honeybadger.io`.
### Honeybadger CLI
[Section titled “Honeybadger CLI”](#honeybadger-cli)
Use the `hb deploy` command in the [Honeybadger CLI](/resources/cli/):
```shell
hb deploy --environment production --repository github.com/org/repo --revision abc123 --user johndoe
```
## Deployment notifications
[Section titled “Deployment notifications”](#deployment-notifications)
Honeybadger can notify your team when your app is deployed. Any of your configured [integrations](/guides/integrations/) — Slack, PagerDuty, email, and more — can be set up to receive deploy notifications. If you’re using the webhook integration, see the [deployed event payload](/guides/integrations/payloads/deployed/) for the payload format.
# Error monitoring
> Collect, manage, and resolve your application errors.
## Installation
[Section titled “Installation”](#installation)
Before you can start using Honeybadger to squash bugs, you will need to install our library into your app. Installation usually boils down to:
1. Installing the Honeybadger library
2. Setting the API key
3. Enabling error reporting
The details vary a little depending on language and platform. But you can always find the correct installation instructions for YOUR app on the “Project Settings” page.
In case you are wondering, we officially support:
[Ruby](/lib/ruby/), [client-side JavaScript](/lib/javascript/), [Vue](/lib/javascript/integration/vue3/), [Elixir](/lib/elixir/), [Go](/lib/go/), [NodeJS](/lib/javascript/integration/node/), [Java](/lib/java/), [Python](/lib/python/), [PHP](/lib/php/), [Clojure](/lib/clojure/), and [Cocoa](/lib/cocoa/)
Check out any of these pages to see how to install Honeybadger for your app. Once our client library is installed and configured, errors thrown by your application are automatically sent to our API.
## Error grouping
[Section titled “Error grouping”](#error-grouping)
Honeybadger groups similar exceptions together using rules which we’ve found to work the best in most cases. The default information we use to group errors is:
1. The file name, method name, and line number of the error’s location
2. The class name of the error
3. The component/controller name
We use this information to construct a “fingerprint” of the exception. Exceptions with the same fingerprint are treated as the same error in Honeybadger.
You can customize the grouping for each exception by changing the error class name, component, or stack trace—or by sending a custom fingerprint.
## Anatomy of an error
[Section titled “Anatomy of an error”](#anatomy-of-an-error)
When your app reports an error to us, we make the details available on a web page that looks like this:
Yeah, it looks a little complicated. But once you understand what all the pieces are, you will see it is quite simple.
Let’s inspect this page, piece by piece.
### Navigating occurrences
[Section titled “Navigating occurrences”](#navigating-occurrences)
Honeybadger groups identical errors together. Using our navigation bar, you can still navigate between each individual occurrence (or notice, as we also call them) of the error.
### Resolve / unresolve
[Section titled “Resolve / unresolve”](#resolve--unresolve)
When an error is marked “unresolved” we will not send you any additional notifications when it re-occurs. Errors are auto-resolved on deploy by default, but that is [configurable](/guides/projects/#resolve-errors-on-deploy).
## Error actions
[Section titled “Error actions”](#error-actions)
Here you can perform many of the actions available to your error. Also, as you set up [integrations](/guides/integrations/) for the project, any that can link back to the error (say, an issue tracker like GitHub) can be managed here.
### Assign an error
[Section titled “Assign an error”](#assign-an-error)
Using this button, you can assign the error currently viewed to any user in the project. This can later be used to search by assignment, or, with assignment notifications enabled, to inform a user that a new error has been assigned to them.
### Pause or ignore an error
[Section titled “Pause or ignore an error”](#pause-or-ignore-an-error)
One of the more common actions used is to ignore the occurrences of an error.
#### Pausing
[Section titled “Pausing”](#pausing)
You can choose to “Pause” for a time duration or occurrence count. We will still record the occurrences, we just will not notify you.
Pausing notifications does not affect the resolved/unresolved status of an error. If you resolve an error while notifications are paused, the next occurrence will still mark it as unresolved — you just won’t be notified about it.
When notifications resume depends on the type of pause:
* **Time-based pause:** Notifications resume on the first occurrence received after the time period has elapsed.
* **Count-based pause:** Notifications resume on the occurrence that exhausts the count (e.g., the 10th occurrence when paused for 10).
In both cases, a notification will be sent even if the error was already reopened by an earlier occurrence during the pause.
#### Ignoring
[Section titled “Ignoring”](#ignoring)
When you “ignore” an error we will stop recording altogether, so it will not go against your quota.
### Resolve on deploy
[Section titled “Resolve on deploy”](#resolve-on-deploy)
By default, Honeybadger resolves all the errors in your project when you [report a deployment](/api/reporting-deployments/), causing new alerts to be sent for any of the errors that re-occur. You can turn off this behavior by unchecking the “Resolve errors on deploy” checkbox in [Project Settings](/guides/projects/#resolve-errors-on-deploy). When turned off, there is a new action in the [actions area](#error-actions) of the error detail page, allowing you to resolve individual errors on the next deploy.
To find errors waiting to be resolved on the next deploy, use the `is:pending_resolution` [search token](/guides/errors/search/#examples).
### Unsubscribe
[Section titled “Unsubscribe”](#unsubscribe)
Unsubscribing from an error disables it from sending notifications - but only for the user currently viewing the error. To silence it for all users, use the pause action.
### Export an error
[Section titled “Export an error”](#export-an-error)
The Export dropdown allows you to download the data for the current error as [Markdown](https://daringfireball.net/projects/markdown/), or export a JSON file of all occurrences via email.
The Markdown version includes the error summary, stack trace, environment details, and breadcrumbs for the current error formatted in standard Markdown syntax compatible with GitHub, Notion, Google Docs, and other Markdown-capable tools.
When exporting all occurrences, you’ll receive an email to download a JSON file containing the data. This file is a [newline-delimited JSON file](https://en.wikipedia.org/wiki/JSON_streaming#Newline-delimited_JSON), which means each line is a valid JSON object. Each of those JSON objects has the data (parameters, context, etc.) for a single occurrence of the error.
### Merge errors
[Section titled “Merge errors”](#merge-errors)
Using the merge action, you can combine one error with another error. This takes all the existing notices from the “donor” error and adds them to the “receiver” error’s notice history.
### Share URL
[Section titled “Share URL”](#share-url)
Sharing the URL of the error will give you a link to a webpage displaying the error. This webpage does not allow for any actions, comments, or the ability to resolve the error.
### Delete
[Section titled “Delete”](#delete)
This removes the error and all of the notice history for that error. This is especially useful if your error information happens to accidentally include sensitive information. New instances of the error will appear again on a new error page.
### Action integrations
[Section titled “Action integrations”](#action-integrations)
GitHub and other project management integrations will add another action button - in GitHub’s case the button is labeled “Create issue”. Other integrations will behave similarly.
## Anatomy of an error, continued
[Section titled “Anatomy of an error, continued”](#anatomy-of-an-error-continued)
Each error page contains a substantial amount of detail related to the error itself and a history of all the actions done to the error. You can see how many times it was resolved or merged and who performed each action.
From the top of the error page, you can see all of the categories and can click to any of them. There’s even a keyboard shortcut for each category.
### Notices
[Section titled “Notices”](#notices)
Note
**Notices** are the individual error events that are sent from your app. We also refer to them as **occurrences**.
The Notices section allows you to see the distribution of occurrences over time. You can constrain the dates and filter using the same search criteria as our [error search](/guides/errors/search/). When you view an error after doing a search, the search criteria will be applied to the notice list.
### Comments
[Section titled “Comments”](#comments)
Communicate with team members, or record notes to retain context around an error. Your comments can be formatted in GitHub-flavored Markdown.
Type `@` in a comment to mention a teammate. An autocomplete menu lets you pick from the project’s members, and mentioned users are notified by email and by in-app notification (subject to their personal alert preferences). Editing a comment to add a new mention also notifies the newly-mentioned user.
### Backtrace
[Section titled “Backtrace”](#backtrace)
Each line in the backtrace links to the GitHub or Bitbucket repo. You can even click a button to open the file in your [local editor](#local-edits).
### Request params, cookies, ENV, etc.
[Section titled “Request params, cookies, ENV, etc.”](#request-params-cookies-env-etc)
When an error occurs during a web request, we record all the relevant debug info like params, cookies, the session, etc.
### Context data
[Section titled “Context data”](#context-data)
Our clients support providing a special set of data called **context**. This data is provided by you to help with debugging. You can use our [search functionality](/guides/errors/search/#search-by-request) to find errors with specific context.
Tip
`user_id` and `user_email` are special context keys that we use to help with looking up users or sending emails (as you can see below.)
## Browsing errors
[Section titled “Browsing errors”](#browsing-errors)
Once you start collecting errors, it can be difficult to keep track of them. To make it easier, we’ve built a great interface for browsing and searching errors.
### Search
[Section titled “Search”](#search)
With advanced search, you can search by any field of params, environment, cookies or the session. Check out our dedicated [search guide](/guides/errors/search/) for more info.
### Batch actions
[Section titled “Batch actions”](#batch-actions)
You can use the *Bulk Update* dropdown to update multiple errors simultaneously. You can apply actions to all search results (this is the default), or you can use the checkboxes in the error list to apply the actions to selected errors.
1. Use the search to select which errors you’d like change.
2. Click on “Actions” and select one or more options from the drop-down.
#### Merging by batch
[Section titled “Merging by batch”](#merging-by-batch)
You can merge two or more errors to create a single error. There are two ways to merge errors:
1. Click the [Merge](#merge-errors) button in the [*Actions*](#error-actions) panel on the error detail page, as described above.
2. Select two or more errors to merge from the [error index page](#browsing-errors) using the checkboxes and use the “Merge to” action in the [*Bulk Update*](#batch-actions) dropdown.
Note: The *Bulk Update* method can merge up to ten thousand error occurrences simultaneously. You can perform multiple updates if necessary.
## Local edits
[Section titled “Local edits”](#local-edits)
One of the advanced features in Honeybadger is configuring your local editor settings so that we can display links to open files locally when showing you an error backtrace:
To configure your editor, [visit the Local Editor tab under My Settings](https://app.honeybadger.io/users/edit#editor). Select the editor you use (if you use a different editor that supports opening files via a custom protocol, [let us know about it](https://www.honeybadger.io/pages/contact)). Next, enter the absolute path to each project you wish to enable local editor links for and click “Save” at the bottom. Re-visit your error pages - they should now have the “Open in editor” links!
Most editors work without any additional setup, but Sublime and Visual Studio Code don’t ship with a custom protocol by default. In order to make them work, you’ll need to install one of these libraries:
* [Sublime 2 handler for OS X](https://github.com/asuth/subl-handler)
* [Sublime 3 handler for OS X](https://github.com/saetia/sublime-url-protocol-mac)
* [Visual Studio Code handler](https://github.com/robyoder/vscode-handler)
If you’re using Atom, make sure you’re on version 1.23 or later for this to work.
Disclaimer: We do not endorse nor support these libraries; they are 3rd party open source software.
## Content Security Policy reports
[Section titled “Content Security Policy reports”](#content-security-policy-reports)
If you use [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) headers to help mitigate XSS attacks, you can use Honeybadger to track policy violations. You can configure the required headers via code when using [Rails](/lib/ruby/integration-guides/rails-exception-tracking/#content-security-policy-reports) or [Sinatra](/lib/ruby/integration-guides/sinatra-exception-tracking/#content-security-policy-reports), or you can configure your web server or framework to emit the headers. Either way, configuring CSP reporting requires specifying the `report-uri` directive:
```plaintext
Content-Security-Policy: ...; report-uri https://api.honeybadger.io/v1/browser/csp?api_key=PROJECT_API_KEY&env=production
Content-Security-Policy-Report-Only: ...; report-uri https://api.honeybadger.io/v1/browser/csp?api_key=PROJECT_API_KEY&report_only=true&env=production
```
The `env` and `report_only` parameters are optional. When `report_only` is true, CSP report payloads will show up as “CSP Report” in our UI; otherwise, the label will be “CSP Error”.
Since CSP violations can be noisy, we strongly suggest you track them in a separate Honeybadger project.
# Error search
> All the ways you can find your errors.
Honeybadger provides powerful search features that let you easily find previously-occurred errors by type, location, meta-data and many other attributes. You can search for errors in a single project, or across all projects.
To search by error type and message, you can simply enter those into the search box. More advanced searches are accomplished via a special query language. We’ve provided a query builder that lets you construct useful queries quickly and easily.
## How to search
[Section titled “How to search”](#how-to-search)
Enter a free-form text value, or one or more `key:"value"` tokens into the search box. Then press enter, or click on the magnifying glass button.
Tokens are separated by spaces. Single and double quotes are allowed.
Example query: `john class:UserError -tag:wip -tag:pending component:"UsersController" action:'update'`.
Because these search queries can become quite complex, we’ve included a query builder that allows you to construct them without much typing. The query builder automatically opens when you focus the search box.
## Natural language search
[Section titled “Natural language search”](#natural-language-search)
You can search for errors without writing the query yourself. Click the lightbulb icon next to the search box to open the “Describe your search” panel, then describe what you want to find. Click Translate and Honeybadger will turn it into a search query.
The translated filter is added to the search bar and runs immediately. You can then edit the query by hand or adjust it with the query builder. This can also be a useful way to learn the query syntax.
**Note:** The NL search uses an LLM, so it may not always get things right. If the translations are not what you expected, please feel free to [reach out to support](mailto:support@honeybadger.io).
## Keyboard navigation
[Section titled “Keyboard navigation”](#keyboard-navigation)
Use the following keyboard shortcuts in the search box as you edit your query. Additional context-sensitive options will be shown to you as you type.
| Key | Response |
| ------------- | -------------------------------------------------- |
| enter | Submits form |
| tab | Tabs to next token and selects value inside quotes |
| shift-tab | Reverse-cycles selected token |
| mod backspace | Deletes selected token |
| escape | Closes hint |
## Keyboard shortcuts
[Section titled “Keyboard shortcuts”](#keyboard-shortcuts)
Quickly search errors using the following keyboard shortcuts while on the error page in the project. Note that these shortcuts immediately trigger a page load and will not preserve the state of the search builder.
| Key | Response |
| ------ | ------------------------------------ |
| / | Focus search box |
| A or a | Show resolved And Unresolved Errors |
| U or u | Show Unresolved Errors |
| R or r | Show Resolved Errors |
| M or m | Show Errors Assigned to Me |
| T or t | Show All Users’ Errors |
| J or j | Jump to another project \* |
| E or e | Show errors in all environments \*\* |
\*This shortcut can be used on any page of the project.
\*\*Use first character of environment name to filter by environment.
## How tokens are combined
[Section titled “How tokens are combined”](#how-tokens-are-combined)
When combining different tokens, we use AND. So `class:MyError assignee:myemail@domain.com` searches for `MyError` instances that are assigned to me.
When combining multiple values for the same token, we use OR. For example, `class:"Foo" class:"Bar" `will return errors with class `Foo` OR `Bar`. There’s one minor exception to this rule. Negative tokens, i.e. tokens preceded by `-` will be combined with AND.
Here are a few examples:
| Example query | Searches |
| --------------------------------------- | --------------------------------------------------- |
| `class:"Foo" is:resolved` | Resolved errors with class `Foo` |
| `-class:"Foo" is:resolved` | Resolved errors without class `Foo` |
| `-class:"Foo" -is:resolved` | Unresolved errors without class `Foo` |
| `class:"Foo" class:"Bar" is:resolved` | Resolved errors with class `Foo` OR class `Bar` |
| `-class:"Foo" -class:"Bar" is:resolved` | Resolved errors without class `Foo` AND class `Bar` |
## Examples
[Section titled “Examples”](#examples)
### Search by state
[Section titled “Search by state”](#search-by-state)
Search errors that are resolved, ignored, paused, or pending resolution, and the inverse of those states. By default, Honeybadger sorts all errors by `-is:ignored` and `-is:resolved`, showing you everything that has not been set as ignored or resolved. These tokens are automatically populated in the search box.
| Example query | Searches |
| ------------------------ | -------------------------------------------------------- |
| `is:resolved` | Resolved errors |
| `-is:resolved` | Unresolved errors |
| `is:paused` | Paused errors |
| `-is:paused` | Errors that aren’t paused |
| `is:ignored` | Ignored errors |
| `-is:ignored` | Errors that aren’t ignored |
| `is:pending_resolution` | Errors that are set to be resolved on the next deploy |
| `-is:pending_resolution` | Errors that aren’t set to be resolved on the next deploy |
### Search by assignee
[Section titled “Search by assignee”](#search-by-assignee)
Errors can be assigned to team members, and results can be refined by assignment. Tokens can be combined to search errors assigned to multiple team members.
| Example query | Searches |
| ---------------------------- | ---------------------------------------- |
| `assignee:"nobody"` | Unassigned errors |
| `assignee:"anybody"` | Errors assigned to anyone |
| `assignee:"jane@email.com"` | Errors assigned to a specific person |
| `-assignee:"jane@email.com"` | Errors not assigned to a specific person |
If other, choose a team member from the drop-down list or begin typing to trigger auto-complete.
### Search by environment
[Section titled “Search by environment”](#search-by-environment)
Search errors by your environment:
| Example query | Searches |
| ---------------------------------- | ----------------------------------- |
| `environment:"production"` | Errors occurring in production |
| `-environment:"production"` | Errors not occurring in production |
| `environment:"development"` | Errors occurring in development |
| `-environment:"development"` | Errors not occurring in development |
| `environment:"custom_environment"` | Errors occurring in any environment |
If other, choose an environment from the drop-down list or begin typing to trigger auto-complete.
### Search by date
[Section titled “Search by date”](#search-by-date)
Search errors by their occurrence. Your timezone is automatically determined but can be changed manually.
| Example query | Searches |
| ----------------------------------------- | --------------------------------------------- |
| `occurred.after:"YYYY-MM-DD 0:00 UTC-7"` | Errors last seen after an exact date |
| `occurred.before:"YYYY-MM-DD 0:00 UTC-7"` | Errors last seen before an exact date |
| `occurred.after:"24 hours ago"` | Errors last seen after a human-friendly date |
| `occurred.before:"24 hours ago"` | Errors last seen before a human-friendly date |
You can enter human-friendly dates like `today`, `this week`, or `July 1`, for example: `occurred.after:"this week"`.
If you want to see errors that **last** occurred as of a certain date — that is, they haven’t occurred again since that date — you can use `last_occurred` instead of `occurred`, like so: `last_occurred.before:"1 week ago"`.
### Search by first seen
[Section titled “Search by first seen”](#search-by-first-seen)
Search errors by when they were first seen. Your timezone is automatically determined but can be changed manually.
| Example query | Searches |
| ---------------------------------------- | ---------------------------------------------- |
| `created.after:"YYYY-MM-DD 0:00 UTC-7"` | Errors first seen after an exact date |
| `created.before:"YYYY-MM-DD 0:00 UTC-7"` | Errors first seen before an exact date |
| `created.after:"24 hours ago"` | Errors first seen after a human-friendly date |
| `created.before:"24 hours ago"` | Errors first seen before a human-friendly date |
You can enter human-friendly dates like `today`, `this week`, or `July 1`, for example: `created.after:"September 12"`.
### Search by error details
[Section titled “Search by error details”](#search-by-error-details)
Search error by class, tag, and message.
| Example query | Searches |
| -------------------------------- | ----------------------------------------------------------- |
| `class:"PermissionDeniedError"` | Errors with a certain class |
| `-class:"PermissionDeniedError"` | Errors without a certain class |
| `tag:"tag_example"` | Errors with a tag |
| `-tag:"tag_example"` | Errors Without a tag |
| `message:"404"` | Errors with a message |
| `-message:"404"` | Errors without message text |
| `has:ticket` | Errors with an associated GitHub issue, Asana task, etc. |
| `-has:ticket` | Errors without an associated GitHub issue, Asana task, etc. |
| `has:comment` | Errors that have comments from team members |
| `-has:comment` | Errors that have no comments from team members |
Class, tag, and message can be combined for specific results. For example, the query: `message:"NameError" class:"TextOrganizer" tag:"priority"` searches errors containing “NameError” from the TextOrganizer class with a “priority” tag.
### Search by location
[Section titled “Search by location”](#search-by-location)
Search errors by component, action, URL, file name, and host.
| Example query | Searches |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `component:"UsersController"` | Errors occurring in a controller/component |
| `-component:"UsersController"` | Errors not occurring in a controller/component |
| `action:"update"` | Errors occurring in an action |
| `-action:"update"` | Errors not occurring in an action |
| `request.url:"https://google.com"` | Errors occurring at a URL |
| `-request.url:"https://google.com"` | Errors not occurring at a URL |
| `request.host:"api.yoursite.com"` | Errors occurring in an application with this in the HTTP\_HOST environment variable (the Host: header provided by the browser) |
| `-request.host:"api.yoursite.com"` | Errors not occurring in an application with this in the HTTP\_HOST environment variable (the Host: header provided by the browser) |
| `file:somefile.rb` | Errors occurring in this file |
| `-file:somefile.rb` | Errors not occurring in this file |
| `hostname:"api-east1-a"` | Errors occurring on a server with this hostname |
| `-hostname:"api-east1-a"` | Errors not occurring on a server with this hostname |
| `revision:"v1.10"` | Errors occurring from a deployment tagged with this revision |
| `-revision:"v1.10"` | Errors not occurring from a deployment tagged with this revision |
Locations can be combined for more specific results. For example, the query: `component:"UsersController" action:"update" request.url:"/docs"` searches errors generated from the update action in the UsersController in the URL `camera`.
### Search by request
[Section titled “Search by request”](#search-by-request)
Search errors by context, params, user agent, or session hashes.
| Example query | Searches |
| ----------------------------------------------- | --------------------------------------------------------------------- |
| `context.user_id:*` | Errors that impacted a user (if you send user\_id in context) |
| `context.user_email:*` | Errors that impacted a user (if you send user\_email in context) |
| `context.user.email:"bob@example.io"` | Errors with a matching context value |
| `-context.user.name:"Bob"` | Errors without a matching context value |
| `params.user.first_name:"Bob"` | Errors with a matching param value |
| `params.old:"useless"` | Errors without a matching param value |
| `request.user_agent:"Googlebot` | Errors caused by a user with this user agent |
| `-request.user_agent:"Googlebot` | Errors not caused by a user with this user agent |
| `request.referer:"http://my.site.com/location` | Errors that occurred when the user came from a particular URL |
| `-request.referer:"http://my.site.com/location` | Errors that occurred when the user did not come from a particular URL |
Requests can be combined or nested for more specific results. For example, searching for context.user.email:bob\@example.com would match the following hash that was sent in the context with an error:
`{ user: { email: "bob@example.com" } }`
When searching these hashes, separate the nested levels of the hash with a period. For example `params.user.first_name:bob`.
Searches against context, params, user agent, or session hashes use \* as a wild-card, so a search for `context.user.email:*@example.com` would match any email address at example.com.
### Searching for arrays
[Section titled “Searching for arrays”](#searching-for-arrays)
When searching for data within array values, one way is to do the search on a key that contains the array value. For example, you might have a sidekiq job that shows up with params in our UI like this:
```ruby
{"job" => {"args" => [{"job_class" => "Foo", "job_id" => "123"}]}}
```
To search for “Foo”, your search should look like this: `params.job.args:*Foo*`
You could be more explicit by including the array index in the query: `params.job.args.0.job_id:123`
## Sorting results
[Section titled “Sorting results”](#sorting-results)
Error results can be sorted by date or error count.
### Sort by date
[Section titled “Sort by date”](#sort-by-date)
Sorting by “Last seen” lets you quickly jump to the newest or oldest exceptions that match your search result.
1. Go to your project’s error list page
2. Click on the table header labeled “last seen”
3. Click on it again to reverse the sort order
### Sort by count
[Section titled “Sort by count”](#sort-by-count)
Sorting by “Times” lets you see which errors have happened the most or the fewest times.
1. Go to your project’s error index
2. Click on the table header labeled “times”
3. Click on it again to reverse the sort order
## Saved searches and default search
[Section titled “Saved searches and default search”](#saved-searches-and-default-search)
You can save a search using the button with the bookmark icon to the right of the button with the search icon. This allows to easily re-use a search. You can also pin a saved search to use that search as the default search. Once you have pinned a search, those search terms will be used as the default view for the project.
## Batch actions
[Section titled “Batch actions”](#batch-actions)
You can use the *Bulk Update* dropdown to update multiple errors simultaneously. You can apply actions to all search results (this is the default), or you can use the checkboxes in the error list to apply the actions to selected errors.
1. Use the search to select which errors you’d like change.
2. Click on “Actions” and select one or more options from the drop-down.
## Free-form text search
[Section titled “Free-form text search”](#free-form-text-search)
Search through your errors by **class** or error **message** by typing your search term into the search box. Free-form text queries can also be combined with `key:value` tokens, for example: `john class:UserError component:UsersController action:update`.
# Heroku
> Honeybadger + Heroku <3.
Honeybadger has great built-in support for Heroku, including automated deployment tracking and monitoring of Heroku [platform errors](https://devcenter.heroku.com/articles/error-codes).
## Overview
[Section titled “Overview”](#overview)
There are two ways to use Honeybadger with Heroku: via our Heroku add-on, and via a regular Honeybadger account. Each has its own unique strengths.
* **Heroku Add-On:** When you purchase the Honeybadger add-on through the Heroku marketplace, you’re buying access for a single project and a single user. If this is all you need, the Heroku add-on can be super convenient. But if you have several users managing errors for multiple projects, it can be a hassle…not to mention more expensive.
* **“Regular” Honeybadger Account:** If you’ve signed up for a Honeybadger account via our website, good news! You still have access to all our Heroku-related features. We’ll cover how to set that up below. You’ll also get a plan that allows multiple projects and multiple users.
### Converting Heroku accounts
[Section titled “Converting Heroku accounts”](#converting-heroku-accounts)
If you are currently a Heroku add-on customer and would like to switch to a “regular” account, we can do that. Just email us at .
## Heroku deployment tracking
[Section titled “Heroku deployment tracking”](#heroku-deployment-tracking)
With deployment tracking, Honeybadger is notified when you deploy your app. It’s optional, but enabling it lets you do some really cool things, like:
* Send alerts to Slack whenever your project is deployed.
* Automatically resolve errors on deployment, so that any new occurrences **after** deployment will send you a new notification.
* See which errors occurred after which deployments.
It’s super easy to set up deployment tracking for your Heroku apps. Just run the following command, making sure to add your Honeybadger API key at the end:
```bash
heroku webhooks:add -i api:release -l notify -u "https://api.honeybadger.io/v1/deploys/heroku?repository=git@github.com/username/projectname&environment=production&api_key=PROJECT_API_KEY" --app app-name
```
If you’re using our Ruby gem, you can use the `honeybadger` command line tool to do the same thing:
```bash
bundle exec honeybadger heroku install_deploy_notification
```
## Heroku platform errors
[Section titled “Heroku platform errors”](#heroku-platform-errors)
> If you’re a Heroku add-on customer, platform error monitoring may already be set up. To check, run `heroku drains -a APP_NAME` and see if it mentions Honeybadger or “logplex.honeybadger.io”. If it does, you don’t need to set anything else up.
Normally, Honeybadger only sees errors that happen inside your application. On Heroku, we’re able to go one step farther and monitor [platform errors](https://devcenter.heroku.com/articles/error-codes). These include the dreaded H12 timeouts and R99 errors you may have seen in your Heroku logs.
To capture these errors we use Heroku’s log drain feature. Each line of your logs is sent to our servers in the background. We pull out the errors and throw everything else away.
To add the log drain, run the following command, replacing API\_KEY with your Honeybadger project’s secret token and APP\_NAME with the name of your Heroku app:
```bash
heroku drains:add https://logplex.honeybadger.io/heroku/v1?api_key=PROJECT_API_KEY-a APP_NAME
```
To monitor different environments in the same Honeybadger project, add the `env` parameter to the log drain endpoint, i.e.:
```bash
heroku drains:add https://logplex.honeybadger.io/heroku/v1?api_key=PROJECT_API_KEY&env=production -a APP_NAME
```
## Heroku platform logs
[Section titled “Heroku platform logs”](#heroku-platform-logs)
To send all of your Heroku logs into [Insights](/guides/insights) (in addition to errors, as described above), create an additional log drain for your Heroku app using an API key displayed on the API keys tab of the project settings page:
```bash
heroku drains:add "https://logplex.honeybadger.io/v1/events?api_key=PROJECT_API_KEY"
```
You can optionally add the `env` parameter to the log drain endpoint. If you do so, each payload recorded from Logplex will have a field named `environment` added to it. You can then add a filter for the desired environment to your queries, like `filter environment::str == 'production'`.
```bash
heroku drains:add https://logplex.honeybadger.io/v1/events?api_key=PROJECT_API_KEY&env=production
```
# Insights & Logging
> Dive into your Honeybadger and application events.
You can use [Honeybadger Insights](https://www.honeybadger.io/tour/logging-observability/) to dive into the data collected by Honeybadger and the logs and other events that you send to our [Events API](/api/reporting-events/). We provide a query language (that we lovingly call [BadgerQL](/guides/insights/badgerql/)) that enables quick discovery of what’s happening inside your applications. The Insights UI also lets you chart the results of those queries and add those charts to [dashboards](/guides/dashboards/) that you can share with your team.
## Querying and visualization
[Section titled “Querying and visualization”](#querying-and-visualization)
Our [query language](/guides/insights/badgerql/) strives to be minimalist, yet powerful. With it you can specify which fields you want to see, filter the kinds of events that should be returned, perform aggregations and calculations, and more. When you first load the Insights UI, you will see a query box that has a default query to help you get started:
```badgerql
fields @ts, @preview
| sort @ts
```
This query selects a couple of special fields — the timestamp and a preview of the fields that are available in the event — and sorts the results by time, with the most recent results first. Each row of the query is piped through the following row, which allows you to apply filters, formatting functions, and so on. Let’s do a quick walk-through to see how it works, and to see how it can be used to create visualizations of your data.
### Walk-through
[Section titled “Walk-through”](#walk-through)
Here’s an example of working with some Honeybadger data. First, filter the data to see only the results of [uptime checks](/guides/uptime/):
```badgerql
fields @ts, @preview
| filter event_type::str == "uptime_check"
| sort @ts
```
You can see that we’ve piped the initial results through `filter`, which accepts a variety of conditions, such as the string comparison shown here. You’ll also notice that we specified the data type of the `event_type` field (`str`) so the query parser can validate the functions and comparisons that you use on the field data.
Clicking on the disclosure arrow will show the all the fields that were stored for an event:
Additional disclosure controls appear inside the event detail view when the event has nested objects.
Let’s filter on some additional data that is present in these events. We can limit the results to show only the uptime checks that originated from our Virginia location, and we can change the fields that we display so we can see some info about the results of each check:
```badgerql
fields @ts, location::str, response.status_code::int, duration::int
| filter event_type::str == "uptime_check"
| filter location::str == "Virginia"
| sort @ts
```
Now let’s summarize the data to find the average response duration for all successful checks:
```badgerql
fields duration::int
| filter event_type::str == "uptime_check"
| filter location::str == "Virginia"
| filter response.status_code::int == 200
| stats avg(duration) by bin(1h) as time
| sort time
```
We use `stats` to perform all kinds of calculations, such as averages, and `by` allows us to specify the grouping for those calculations. Grouping by `bin` gives us time-series data, which makes it easy to create a chart by clicking the Line button.
From there you can experiment with different visualizations, update the query to change the chart (try changing `1h` to `15m`), and add the chart to a custom dashboard.
Of course, this functionality isn’t limited to only the data that is generated by Honeybadger. Your error data is also available for querying (`event_type::str == "notice"`), and you can send logs and events to our [API](/api/reporting-events/) to be able to query and chart your own data.
### Natural language queries
[Section titled “Natural language queries”](#natural-language-queries)
You don’t need to know [BadgerQL](/guides/insights/badgerql/) to query your data. Click the lightbulb icon to the right of the query editor to open the natural language translator panel. Describe what you want to see, then press `⌘+Enter` or click Translate and Honeybadger will write the query for you.
The translator uses your current query as context, so you can build up a query in steps. Start broad, then ask for changes like including the duration, grouping by controller, or narrowing to just 5xx status codes.
You can also include other display options in your description. For example, ask for “the last hour” or “as a line chart” and Honeybadger will update the time range or visualization.
**Note:** The NL translator uses an LLM, so it may not always get things right. If the translations are not what you expected, please record your feedback via the thumbs, or feel free to [reach out to support](mailto:support@honeybadger.io).
### Streams
[Section titled “Streams”](#streams)
Streams are the fundamental data sources in Honeybadger Insights. They serve as the starting point for your queries and represent the data you want to analyze.
When you create a new Honeybadger project, we automatically set up two streams for you:
**Internal stream**
The Internal Stream is a dedicated stream that stores all Honeybadger-generated events related to your project. This includes errors, deployments, notifications, uptime checks, and other internal Honeybadger data. You cannot directly send custom events to the Internal Stream, as it is managed by Honeybadger itself.
**Default stream**
The Default Stream is the primary stream for storing custom events that you send using Honeybadger client libraries or the Honeybadger API. Any event data you explicitly send to Honeybadger will be stored in the Default Stream.
#### The stream selector
[Section titled “The stream selector”](#the-stream-selector)
You can select the active streams from the stream selector at the top of the query editor. This affects the data that Insights returns for your queries.
Removing a stream you don’t need can improve your query response times, because then Insights doesn’t need to scan that data when executing your query. So for example, if you’re just querying your application logs, you can remove the *Internal* stream to get a faster response.
## Working with dashboards
[Section titled “Working with dashboards”](#working-with-dashboards)
[Dashboards](/guides/dashboards/) allow you to collect different types of charts and query results on a single page. Any query or chart that you generate can be added to a dashboard, which will then be shared with the rest of your team. Each widget on a dashboard includes a link to view the query and raw results behind the widget:
If you change the query or the visualization, you can save those changes back to your dashboard, or add them as a widget to a new dashboard.
We provide some [automatic dashboards](/guides/dashboards/#automatic-dashboards) to get you started. For example, when you [add a Heroku drain](/guides/insights/integrations/heroku/) to your app, the [automatic Heroku dashboard](/guides/dashboards/heroku/) will show data like the number of requests grouped by response code that we automatically collect from [Logplex](https://devcenter.heroku.com/articles/logplex).
To learn more about dashboards, see the [dashboards guide](/guides/dashboards/).
## Adding data from other sources
[Section titled “Adding data from other sources”](#adding-data-from-other-sources)
Insights includes all the events that Honeybadger collects, such as error notifications, uptime checks, and check-in reports, but you can send your own event data as well.
Our [API](/api/reporting-events/) accepts newline-delimited JSON, where each line is a JSON object that describes an event that you care about. You can send user audit trail events, metrics, or any other data you’d like to query and analyze. The type of data most frequently sent to Insights is application log data.
Sending structured logs in a JSON format (like [lograge](https://github.com/roidrage/lograge) produces) allows you to correlate what’s happening in your app with the error data that Honeybadger is already recording for you. See our integration guides to learn how you can easily send log events from sources such as Heroku apps and CloudWatch Logs.
[Ruby and Rails apps](/guides/insights/integrations/ruby-and-rails/)Send metrics and events from Ruby and Rails apps to Honeybadger Insights
[Elixir/Phoenix apps](/guides/insights/integrations/elixir-phoenix/)Send logs and events from Elixir/Phoenix apps to Honeybadger Insights
[JavaScript apps](/guides/insights/integrations/javascript/)Send metrics and events from JavaScript apps to Honeybadger Insights
[PHP/Laravel apps](/guides/insights/integrations/php-laravel/)Send metrics and events from PHP/Laravel apps to Honeybadger Insights
[OpenTelemetry (Beta)](/guides/insights/integrations/opentelemetry/)Send traces, metrics, and logs via the OpenTelemetry Protocol (OTLP)
[CloudWatch Logs](/guides/insights/integrations/cloudwatch-logs/)Stream AWS CloudWatch Logs to Honeybadger Insights
[Crunchy Bridge](/guides/insights/integrations/crunchy-bridge/)Send Crunchy Bridge metrics to Honeybadger Insights
[Fly.io](/guides/insights/integrations/fly-io/)Send Fly.io app metrics to Honeybadger Insights
[Heroku](/guides/insights/integrations/heroku/)Send Heroku app metrics to Honeybadger Insights
[Host metrics](/guides/insights/integrations/host-metrics/)Send host metrics to Honeybadger Insights
[Log files](/guides/insights/integrations/log-files/)Use Vector to ship your log files to Honeybadger Insights
[Netlify](/guides/insights/integrations/netlify/)Send Netlify function logs to Honeybadger Insights
[Rsyslog](/guides/insights/integrations/rsyslog/)Forward rsyslog messages to Honeybadger Insights over syslog-TLS
[Systemd (journald)](/guides/insights/integrations/systemd/)Ship systemd journal logs to Honeybadger Insights
# Alarms guide
> Learn how to create Honeybadger alarms to monitor your Insights data in real time.
Insights alarms allow you to monitor your data in real time and get notified under the conditions you set. Your Honeybadger data, such as errors, deployments, and uptime checks, are already available to query. To learn how to send your own custom data to Honeybadger, see the [Getting started guide](/guides/insights/). Then, you can create alarms for anything your business needs.
## Viewing an alarm
[Section titled “Viewing an alarm”](#viewing-an-alarm)
Alarms combine a [BadgerQL](/guides/insights/badgerql/) query (“count all slow requests in the past five minutes”) with a threshold (“when count is > 2”) and trigger alerts when the query result exceeds the threshold.
In the above chart, the red line is the threshold for the alarm state. This query was in an alarm state for one period in the last hour but recently recovered.
## Creating or updating an alarm
[Section titled “Creating or updating an alarm”](#creating-or-updating-an-alarm)
### Query and timing
[Section titled “Query and timing”](#query-and-timing)
Construct a `query` using [BadgerQL](/guides/insights/badgerql/) to return data you wish to monitor. You may want to use a `filter` function to isolate the relevant data.
Use the `interval` field to specify the time window for the query. The `interval` field is a string that represents the time window for the query. The format is `1d`, `1h`, `1m`, etc. In other words, the `interval` is both the frequency and the time period over which the query is executed.
The `lag` field can be used to delay the query execution by a specified time period. The `lag` field is also a string that represents the time delay for the query. The format is `1d`, `1h`, `1m`, etc. This is useful when you want to wait for slow or late data arriving.
### Result count
[Section titled “Result count”](#result-count)
Alarms are triggered based on the number of results returned by the query. You can specify the logical comparison operator (`>`, `>=`, `<`, `<=`, `==`, `!=`) and a value count. The alarm will trigger when the number of results meets the condition.
### Description
[Section titled “Description”](#description)
It may be helpful to provide a description of the alarm to help you remember its purpose. The description is also delivered as part of the notification when you have integrations setup. Some useful information would be what the alarm is monitoring, what to do when the alarm triggers, and who to contact.
## Integrations
[Section titled “Integrations”](#integrations)
Integrations is where you can configured how to be notified when an alarm changes state. There are two states per integration that can be configured: `ok` and `alert`.
All users can update their personal notification integrations (email, etc.), while users with administrator access to the project can manage the alert settings for all of the project’s integrations.
# Archive destinations
> Replicate Honeybadger Insights stream data to an S3-compatible bucket you own.
Archive destinations replicate the events flowing into your Honeybadger [Insights streams](/guides/insights/#streams) to an S3-compatible bucket that you own and control. Once a destination is configured and a stream is attached, Honeybadger writes a continuous archive of that stream’s events into your bucket.
This is useful for long-term retention beyond your Insights data window or for feeding events into your own data warehouse or lake.
## What gets archived
[Section titled “What gets archived”](#what-gets-archived)
Only the events that flow through your Insights streams are replicated:
* The custom events your application sends to Insights via the [Events API](/api/reporting-events/) or a Honeybadger client library.
* The internal events Honeybadger generates for your project — error notifications, deployments, uptime checks, check-in reports, and so on.
Detailed error data such as backtraces, breadcrumbs, and environment variables is **not** included. Archive destinations replicate distilled stream events, not full error payloads.
You choose which streams replicate to which destination, so you can archive just your application events, just the internal Honeybadger events, or both.
## Supported providers
[Section titled “Supported providers”](#supported-providers)
You can point a destination at any of these S3-compatible providers:
* Amazon S3
* Cloudflare R2
* Google Cloud Storage (S3-compatible interop endpoint)
* Wasabi
* Backblaze B2
* DigitalOcean Spaces
The endpoint must use HTTPS. AWS S3 buckets are detected from the bucket name and don’t require an endpoint URL — for the others, set the provider’s S3-compatible endpoint URL on the destination.
## Setting up a destination
[Section titled “Setting up a destination”](#setting-up-a-destination)
Archive destinations are managed at the account level under **Account Settings → Archive Destinations**.
### 1. Create the bucket
[Section titled “1. Create the bucket”](#1-create-the-bucket)
Create a bucket on your provider of choice. A fresh bucket dedicated to Honeybadger archives is the simplest setup, but you can also add archives to an existing bucket by configuring a prefix on the destination.
### 2. Create credentials
[Section titled “2. Create credentials”](#2-create-credentials)
Create an access key and secret with permission to write to that bucket. The archiver only needs to upload objects — at minimum:
* `s3:PutObject` on the bucket (scoped to your prefix is fine)
No read, list, or delete permissions are required. We recommend creating a dedicated IAM user (or equivalent on your provider) scoped to just the archive bucket so the credentials you give Honeybadger can’t reach anything else.
For example, on AWS S3 a minimal policy looks like:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
]
}
```
If you scope to a prefix, change the resource to `arn:aws:s3:::your-bucket-name/your-prefix/*`.
Objects are uploaded with AES-256 server-side encryption (SSE-S3) by default. If your bucket policy enforces a specific encryption type, make sure SSE-S3 is allowed.
### 3. Add the destination in Honeybadger
[Section titled “3. Add the destination in Honeybadger”](#3-add-the-destination-in-honeybadger)
In **Account Settings → Archive Destinations**, click **New destination** and fill in:
* **Name** — a short label that’s unique within your account.
* **S3 bucket** — the bucket name.
* **Prefix** *(optional)* — a key prefix that all archived objects will be written under. Useful if the bucket is shared with other data.
* **Region** *(optional, required for AWS S3)* — e.g. `us-west-2`.
* **Endpoint URL** *(optional)* — leave blank for AWS S3. Set this to the provider’s S3-compatible endpoint for R2, GCS, Wasabi, Backblaze, or DigitalOcean Spaces.
* **Access key ID** and **Secret access key** — the credentials from step 2.
Credentials are encrypted at rest. When editing an existing destination, leave the credential fields blank to keep the stored values; fill them in to rotate.
### 4. Attach streams
[Section titled “4. Attach streams”](#4-attach-streams)
A destination with no streams attached is **paused** — nothing replicates until you select at least one stream. On the destination form, pick the streams you want to replicate. Each stream can only be attached to one destination at a time.
Streams start replicating on the next archive cycle. There’s no backfill — only events ingested after a stream is attached will land in your bucket.
## File structure
[Section titled “File structure”](#file-structure)
Objects are gzip-compressed JSON Lines (one event per line, served with `Content-Type: application/jsonl`). The key layout is:
```plaintext
[prefix/]insights/{stream_id}/{YYYY}/{MM}/{DD}/{HH}/{unix_timestamp}_{random_hex}.jsonl.gz
```
For example, with prefix `honeybadger`:
```plaintext
honeybadger/insights/abc123/2026/04/30/14/1714485612_a3f80c1d4e2b9876.jsonl.gz
```
The path components:
* `prefix/` — the optional prefix you configured on the destination.
* `insights/{stream_id}/` — fixed prefix plus the stream ID.
* `{YYYY}/{MM}/{DD}/{HH}/` — UTC ingestion hour the events fell into. This is based on when the events were received by Honeybadger, not when the file was written, so a delayed write still lands in the hour it logically belongs to.
* `{unix_timestamp}_{random_hex}.jsonl.gz` — a unique object name within the hour.
Each object decompresses to JSON Lines: one JSON object per line, one event per line.
## Object frequency
[Section titled “Object frequency”](#object-frequency)
Honeybadger periodically writes new objects into your bucket for each active stream. The exact cadence isn’t guaranteed and may vary over time, so the important model to keep in mind is:
> Concatenating every object under a stream’s prefix gives you that stream’s full event history.
No single object contains all of a stream’s events — each object is a fragment. To reconstruct events for a time range, list every object under `insights/{stream_id}/{YYYY}/{MM}/{DD}/{HH}/` for the hours you care about and concatenate their decompressed contents. Tools like AWS Athena, DuckDB, ClickHouse, and most data warehouses can read directories of gzipped JSON Lines files directly without needing to merge them yourself.
## Status, pauses, and errors
[Section titled “Status, pauses, and errors”](#status-pauses-and-errors)
Each destination is in one of three states:
* **Active** — at least one stream is attached and writes are succeeding.
* **Paused** — the destination is configured but no streams are attached. Attach a stream to start.
* **Errored** — Honeybadger has stopped writing to the bucket. Events for attached streams are dropped until you fix the destination and reactivate it.
Honeybadger transparently handles short-term failures on the bucket’s side — we retry and buffer events through network blips, timeouts, and brief outages, so most disruptions recover without you noticing. If a destination keeps failing or hits a problem we can’t recover from on our own (invalid credentials, a missing bucket, a permission change), we move it to the **errored** state and email the account owner with the details. The destination card shows the last error message and when it occurred.
To recover, fix the underlying issue and either save the destination with corrected credentials — a successful save reactivates it automatically — or click **Reactivate** if only a transient issue needed clearing.
If the underlying problem isn’t actually fixed, the next archive write will flip the destination back to errored.
## Deleting a destination
[Section titled “Deleting a destination”](#deleting-a-destination)
Deleting a destination immediately stops new writes for any attached streams. Objects that have already been written to your bucket are **not** deleted — they’re yours, and Honeybadger never reads or removes them after upload.
If you want to fully clean up, delete the bucket (or the objects under your prefix) yourself once you no longer need the archived data.
# BadgerQL guide
> Learn how to use BadgerQL to query your log events and observability data in Honeybadger Insights.
BadgerQL is the language you use to interact with your data stored in Insights. It was designed to enable you to enrich, shape, and combine your events so you can craft any view of your data. Quick reference docs are also available in the application via the book icon in the top-right corner of the query box.
We also provide inline hints in the query editor that show info from the quick reference docs as you type:
Need a hand crafting BadgerQL queries? The natural language query translator can [translate plain-English descriptions](/guides/insights/#natural-language-queries) into queries, visualizations, and time ranges.
## Example queries and use cases
[Section titled “Example queries and use cases”](#example-queries-and-use-cases)
Find N+1 queries in your Rails app:
```badgerql
filter event_type::str == "sql.active_record"
| stats count() as queryCt, sum(duration::float) by request_id::str, query::str
| sort queryCt desc
```
What events are consuming my Insights quota?
Be sure to deselect the [Internal Stream](/guides/insights/#streams) so you only see the data you are sending:
```badgerql
stats sum(@size) as size by event_type::str
| sort size
| only toHumanString(size, "bytes"), event_type
```
See more examples in the [walk-through](/guides/insights/#walk-through) or review the full BadgerQL reference below for more information.
## Parameterized queries
[Section titled “Parameterized queries”](#parameterized-queries)
Parameterized queries let you swap values into a query at runtime without editing the query itself. You can filter a dashboard to a single host, environment, or customer; share a prefilled URL with a teammate; or reuse the same widget across multiple contexts.
Parameters work anywhere you write BadgerQL, including dashboard widgets and the Insights query editor.
Use `${name}` to reference a parameter in a query:
```badgerql
filter hostname::str == "${hostname}"
```
Provide a default with `${name:-default}`:
```badgerql
filter env::str == "${env:-production}"
```
Parameter names must start with a letter or underscore, followed by letters, numbers, or underscores.
Parameter values can be provided in the URL (e.g., `?hostname=web-01`), allowing you to share query URLs with prefilled values, or by clicking the parameters button (the slider icon in the dashboard toolbar, next to the date picker) to open a popover with a field for each parameter used in the query.
## Functions to enrich, shape, and combine data
[Section titled “Functions to enrich, shape, and combine data”](#functions-to-enrich-shape-and-combine-data)
Functions are the core of BadgerQL. You can think of your data falling or piping through each function that you specify, getting filtered, aggregated, and so on along the way. The most common functions you will use are [`fields`](#fields) to select fields to view, [`filter`](#filter) to restrict what data appears in the results, and [`stats`](#stats) to do counts, averages, and other analyses. Keep reading to learn about all the functions we offer.
### Combining functions
[Section titled “Combining functions”](#combining-functions)
While calling a BadgerQL function on its own can produce interesting results, the real power comes when piping functions together via the pipe (`|`) operator:
```badgerql
fields status_code::int, controller::str
| filter startsWith(controller, "Stripe")
| stats count() by status_code
```
Each function builds off the other to create a result showing the distribution of status codes just for Stripe controller requests.
Note that BadgerQL does not work like SQL. Each successive function is applied to the result of the previous, so you can only reference fields down the pipeline.
For example, if you want to convert a string to a number gathered from a `parse` function, you can pipe into another `fields` function:
```badgerql
parse url::str /id=(?\d+)/
| fields toInt(id) as id
```
### Expand
[Section titled “Expand”](#expand)
You can use `expand` to turn an event that has a field with array data into multiple events.
```badgerql
expand array_field [as alias][, ...]
```
With data that has a single event like `{"id": 1, "charges": [700, 430, 200]}`, the following query will return three events, with `id` and `charge` fields:
```badgerql
expand charges[*]::int as charge
```
See the [Arrays](#arrays) section for more detail on working with array data.
### Fill
[Section titled “Fill”](#fill)
Use `fill` to inject events for missing data points.
```badgerql
fill field_expression [as alias] [asc|desc|up|down] [from ...] [to ...] [step ...] [across field [bounded | including [...]]]* [with field[ = expression][, ...]*]
```
Unless specified with `from` or `to`, `fill` will determine the min and max values of the `field_expression`, sort, and produce new events with missing `field_expression` values replaced by the incremented or decremented step value.
`field_expression` only allows for `number` or `temporal` types. The resulting optional clause types differ based on the resolved type:
```badgerql
fill number [from number] [to number] [step number]
fill temporal [from temporal] [to temporal] [step interval]
```
Fill works best when referencing an already existing field. Since fill inserts data at a regular interval, you will also get the best results if the field follows the step size of the fill.
#### Typical usage
[Section titled “Typical usage”](#typical-usage)
Take a `stats` call that bins the count of events per hour:
```badgerql
stats count() as ct by bin(1h) as bin
```
You might get sparse results if there is not enough data to fill each bin:
| ct | bin |
| -- | ----------------------- |
| 5 | 2023-04-05 02:00:00.000 |
| 10 | 2023-04-05 04:00:00.000 |
| 2 | 2023-04-05 06:00:00.000 |
With the `fill` function (the step is inferred from `bin()`, so a bare `fill bin` is enough):
```badgerql
stats count() as ct by bin(1h) as bin
| fill bin
```
You can produce a full binned result set:
| ct | bin |
| -- | ----------------------- |
| 5 | 2023-04-05 02:00:00.000 |
| 0 | 2023-04-05 03:00:00.000 |
| 10 | 2023-04-05 04:00:00.000 |
| 0 | 2023-04-05 05:00:00.000 |
| 2 | 2023-04-05 06:00:00.000 |
#### Automatic step from `bin()` and `bucket()`
[Section titled “Automatic step from bin() and bucket()”](#automatic-step-from-bin-and-bucket)
If the fill field comes from a `bin()` or `bucket()`, you don’t need to repeat the step. `fill` picks it up automatically. `bin(1h)` gives you a 1-hour step, `bucket(x, 100)` gives you a 100-wide step, and the bounded form `bucket(x, 0, 1000, 20)` gives you from, to, and step all at once. You can still pass an explicit `step`, `from`, or `to` to override.
```badgerql
stats count() as ct by bucket(duration::int, 0, 2000, 20) as ms
| fill ms
| sort ms asc
```
The bucket width is `2000 / 20 = 100`, so `fill` inserts a row for every 100-wide slot that had no matching events:
| ct | ms |
| -- | --- |
| 12 | 0 |
| 0 | 100 |
| 0 | 200 |
| 45 | 300 |
| 30 | 400 |
| 0 | 500 |
| … | … |
#### Filling across dimensions
[Section titled “Filling across dimensions”](#filling-across-dimensions)
Add `across ` to fill every combination of the fill field and a grouping dimension. This is useful for stacked charts, heatmaps, or any per-category series where you want explicit zeros instead of missing rows.
```badgerql
stats count() as count by bin(1h) as t, status::str
| fill t across status
```
Every combination of time bin and status gets a row, with 0 for missing cells:
| count | t | status |
| ----- | ----------------------- | ------ |
| 8 | 2023-04-05 02:00:00.000 | 200 |
| 0 | 2023-04-05 02:00:00.000 | 500 |
| 0 | 2023-04-05 03:00:00.000 | 200 |
| 3 | 2023-04-05 03:00:00.000 | 500 |
You can chain multiple `across` clauses:
```badgerql
stats count() as count by bin(1h) as t, status::str, region::str
| fill t across status across region
```
Counting aggregates (`count`, `sum`, `unique` and their `*If` variants) default to 0 on filled cells. Everything else defaults to null. Use `with field = value` to pick a different default.
##### `bounded`
[Section titled “bounded”](#bounded)
Without `bounded`, `across` fills every category across the entire range of the fill field. Say `temp` reported from 02:00–04:00 and `humidity` only reported at 05:00. Plain `across` would create rows for both sensors across the full 02:00–05:00 range. `across field bounded` limits each category to its own observed range instead:
```badgerql
stats count() as count by bin(1h) as t, sensor::str
| fill t across sensor bounded
```
| count | t | sensor |
| ----- | ----------------------- | -------- |
| 5 | 2023-04-05 02:00:00.000 | temp |
| 0 | 2023-04-05 03:00:00.000 | temp |
| 3 | 2023-04-05 04:00:00.000 | temp |
| 7 | 2023-04-05 05:00:00.000 | humidity |
No rows for `humidity` at 02:00–04:00, and no rows for `temp` at 05:00.
You can’t combine `bounded` with `including` on the same dimension, or with explicit `from`/`to`.
##### `including`
[Section titled “including”](#including)
`across field including [...]` ensures specific values show up in the result even if they’re missing from the data. The pinned values are added on top of whatever the query discovers, so you won’t lose any existing categories. All values in the array must be the same type.
```badgerql
stats count() as count by bin(1h) as t, op::str
| fill t across op including ["create", "delete"]
```
The `"create"` and `"delete"` values appear even if the data only contains `"update"` events:
| count | t | op |
| ----- | ----------------------- | ------ |
| 0 | 2023-04-05 02:00:00.000 | create |
| 0 | 2023-04-05 02:00:00.000 | delete |
| 4 | 2023-04-05 02:00:00.000 | update |
| 1 | 2023-04-05 03:00:00.000 | create |
| 0 | 2023-04-05 03:00:00.000 | delete |
| 0 | 2023-04-05 03:00:00.000 | update |
This is also useful for keeping chart legends stable. If a category has zero events across the entire query range, `across` alone won’t include it. `including` pins those categories into the result so they always appear.
Note
`across` does not support fill direction (`up`/`down`) or carry-forward `with field`. Use `with field = value` instead.
#### Fill order
[Section titled “Fill order”](#fill-order)
By default, the fill function sorts the `field_expression` in ascending order before injecting fill events. You can change this by providing an order direction after the `field_expression`:
```badgerql
fill @ts desc step -1h
```
When filling in descending order, `from` must be greater than `to` and `step` must be a negative value.
#### `@fill` internal field
[Section titled “@fill internal field”](#fill-internal-field)
Filled events have an additional internal `@fill` field added to the results. You can use this field to determine when an event is filled:
```badgerql
fields @fill
| fill duration::int from 100 to 500 step 100
```
| @fill | duration |
| ----- | -------- |
| true | 200 |
| true | 300 |
| | 325 |
| true | 400 |
#### Filling other fields
[Section titled “Filling other fields”](#filling-other-fields)
Most fields other than `field_expression` will be filled with a null value for injected events. You can control what data is replaced using the `with` clause. Setting the `with` field to the `field_expression` will result in an error.
If `with` is given only a field, it will carry over the field value from the previous event:
```badgerql
fields @fill, controller::str
| fill duration to 340 step 10 with controller
```
| @fill | duration | controller |
| ----- | -------- | ---------- |
| | 300 | login |
| true | 310 | login |
| | 320 | sign-up |
| true | 330 | sign-up |
`with` fields can also be set to specific values for filled events:
```badgerql
stats avg(temp::float) as avgTemp by bin(1d) as bin
| fill bin step 1d with avgTemp = 65.0
```
| avgTemp | bin |
| ------- | ---------- |
| 73.3 | 2023-04-08 |
| 65.0 | 2023-04-09 |
| 68.9 | 2023-04-10 |
| 65.0 | 2023-04-11 |
Referencing other fields from previous events is also possible, acting like a `LAST_VALUE()` window function.
#### Notes
[Section titled “Notes”](#notes)
* Having multiple fills is possible by piping together `fill` functions, but take care to ensure you are not injecting too many events.
* `from` and `to` values are not inclusive when producing injected results.
### Fields
[Section titled “Fields”](#fields)
The `fields` function enriches your results by adding extra fields. Any fields that you select or alias can be referenced in later functions, and they will be returned in the final dataset unless rewritten by later functions.
```badgerql
fields expr [as alias][, ...]*
```
Fields can be aliased with the `as` clause, and unsupported characters (like spaces) can be used by using backticks.
```badgerql
fields user_name::str as `User name`
```
Aliased fields can be used in later functions:
```badgerql
fields concat(first_name::str, " ", last_name::str) as full_name
| filter full_name match /^Bob.*/
```
#### Internal fields
[Section titled “Internal fields”](#internal-fields)
We set the following internal fields for you as the data is ingested:
| Name | Type | Description |
| ----------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `@id` | `String` | The event ID |
| `@ts` | `DateTime` | The reported timestamp if provided as `ts` or `timestamp`; otherwise, the time when the event was received |
| `@received_ts` | `DateTime` | The time when the event was received |
| `@stream.id` | `String` | The ID of the stream that contains the event. Each project contains at least two streams: the internal Honeybadger stream used for notices, etc., and the stream used for storing events that you send to our API. |
| `@stream.name` | `String` | The name of the stream |
| `@query.start_at` | `DateTime` | The timestamp of start of the range queried. E.g., when searching back 3 hours (the default), this will be three hours ago |
| `@query.end_at` | `DateTime` | The timestamp of end of the range queried. E.g., for the default query, this would be the time when the query was executed, since the default query searches for data up to the time the query was sent. |
| `@size` | `Integer` | The size in bytes of the event |
| `@fill` | `Boolean` | Whether the result has filled-in values |
| `@preview` | `JSON Object` | A preview of the data stored for the event |
### Filter
[Section titled “Filter”](#filter)
Filter expects a body that results in a boolean expression, and it will exclude events where the expression returns false.
```badgerql
filter boolean_expr [and|or ...]*
```
Multiple piped filter functions will act as AND operations.
```badgerql
filter controller_name::str == "StripeController" and duration::float > 2000
| filter action_name::str == "hook"
```
### Limit
[Section titled “Limit”](#limit)
Limit the number of results returned by the query.
```badgerql
limit integer [by expr[, ...]*]
```
Caution
Limiting can adversely affect piped function results. For example, adding a `limit` before a `stats` call will only gather stats on the limited events:
```badgerql
limit 10
| stats count() by controller::str
```
If you want to restrict the number of returned results, make sure `limit` is at the end of your pipeline:
```badgerql
stats count() by controller::str
| limit 10
```
Include a `by` clause to limit the number of results per group.
```badgerql
limit 10 by user_id::int
```
Pipe into `limit` to restrict the final number of results returned by the query.
```badgerql
limit 5 by user_id::int
| limit 100
```
### Only
[Section titled “Only”](#only)
Use `only` to restrict which fields are rendered in the results and in which order they will appear.
```badgerql
only expr [as alias][, ...]*
```
For example, if you want to filter on a particular field, but you don’t want that field to appear in the results, you can use `only` to select the fields you want to see:
```badgerql
fields a, b, c
| filter c > 2
| only b, a
```
### Parse
[Section titled “Parse”](#parse)
Extract fields using regular expressions
```badgerql
parse expr /regex/
```
If your events have data that can be extracted using regular expressions, you can create fields from that data. The following example will extract “redis” from an event that has a field named “addon” that contains the value “redis-fitted-71581” and place it in a new field called “service”. Both the “addon” and “service” fields will appear in the results.
```badgerql
fields addon::str
| parse addon /(?[[:alpha:]]+)/
```
### Sort
[Section titled “Sort”](#sort)
Order events based on fields.
```badgerql
sort expr [desc|asc][, ...]*
```
Queries without an explicit sort are unordered and non-deterministic. Sort direction can be either `desc` (descending) or `asc` (ascending). By default, fields are sorted in descending order if not specified.
```badgerql
sort day desc, duration asc
```
Sort is useful to order results by time, or when calculating stats:
```badgerql
fields email
| filter action::str == "Logged in"
| stats count() as count by email
| sort count
```
It can make sense to call `sort` multiple times, as sorting after rewriting functions might be necessary.
### Stats
[Section titled “Stats”](#stats)
Aggregate event fields
```badgerql
stats agg_expr[, ...]* by [expr][, ...]*
```
The workhorse of Insights, `stats` allows you to perform calculations on your data. You can count events, calculate averages, and more.
```badgerql
stats avg(response_time::float)
```
Note
Results from `stats` are unsorted by default, even if the events piped into `stats` are sorted. Pipe into `sort` if order matters.
#### Aggregation
[Section titled “Aggregation”](#aggregation)
Available aggregate functions:
| Function | Description |
| ------------------------------- | ---------------------------------------------------------------------------------------- |
| `count()` | Returns the total count of all results. Can contain an expression that filters the count |
| `avg(field)` | Calculates the average (mean) value for a numeric field |
| `min(field)`, `max(field)` | Returns the minimum/maximum value for the given field |
| `sum(field)` | Calculates the sum of values for a numeric field |
| `percentile(percentage, field)` | Returns the value at the specified percentile for the given numeric field |
| `unique(field)` | Returns the number of unique values for the specified field |
| `first(field)`, `last(field)` | Returns the first/last value of the specified field for the whole aggregate |
| `apdex(field, threshold)` | Calculates an Apdex (Application Performance Index) score between 0 and 1 |
Find the number of 500 errors over a time period:
```badgerql
filter status_code::int == 500
| stats count()
```
Find the average response time for a specific endpoint:
```badgerql
filter endpoint::str == "/api/v1/orders"
| stats avg(duration::float)
```
Combine multiple aggregate functions in a single query:
```badgerql
filter environment::str in ["production", "staging"]
| stats count(), percentile(95, duration::float)
```
#### Grouping
[Section titled “Grouping”](#grouping)
The `by` clause allows you to group the results by one or more fields.
```badgerql
stats avg(response_time::float) by location::str
```
One of the most common use cases for grouping is to create a time series by grouping with `bin()`.
#### The `bin()` function
[Section titled “The bin() function”](#the-bin-function)
`bin()` rounds a datetime down to the nearest interval boundary, which lets you group events into time buckets (e.g., “all events in this 1-hour window”).
```plaintext
bin([interval[, datetime]])
```
Both arguments are optional:
* **`interval`** — the bucket size, written using interval syntax (e.g. `1h`, `30m`, `2d`). If omitted, `bin()` automatically picks a reasonable size based on your selected time range.
* **`datetime`** — the field to bin. Defaults to `@ts`. Use this when you want to bin on a field other than the event timestamp.
```badgerql
stats count() by bin(1h) as time
```
```badgerql
stats count() by bin(1h, toDateTime(user.created_at::str)) as time
```
When no alias is given, the result column is named after the call itself (e.g. `bin(1h)`). Always alias `bin()` when you need to reference it in a later function like `sort` or `fill`.
**Interval syntax** — an integer followed by a unit abbreviation:
| Unit | Abbreviation | Example |
| ------- | ------------ | ------- |
| Seconds | `s` | `30s` |
| Minutes | `m` | `15m` |
| Hours | `h` | `1h` |
| Days | `d` | `7d` |
| Weeks | `w` | `1w` |
| Months | `mon` | `1mon` |
**Auto-sizing** — when `bin()` is called with no interval argument, the bin size is automatically chosen to produce a reasonable number of buckets for your selected time range.
```badgerql
stats count() by bin() as time, status_code::int
```
You can use any field or expression in the `by` clause:
```badgerql
stats avg(duration::float), max(duration::float)
by bin() as time, concat(controller::str, "#", action::str) as controllerAction
```
### Unique
[Section titled “Unique”](#unique)
The `unique` function filters out duplicate events based on the field(s) you specify.
```badgerql
unique field[, ...]
```
### Toggling functions
[Section titled “Toggling functions”](#toggling-functions)
**Hotkey: `CTRL + /`**
When exploring data in BadgerQL, you might find it useful to temporarily ignore certain functions while keeping them in the query.
To do this, add a bang (`!`) at the beginning of the BadgerQL function. This comments out the function, effectively ignoring it without removing it from the query.
This is particularly useful for toggling conditions in statistical analyses. For example, you might want to alternate between including and excluding certain filters:
```badgerql
fields event_type::str, duration::int
| filter event_type == "page_view"
| !filter duration > 100
| stats count() by bin(1d)
```
Note that if a function spans multiple lines, placing a bang (`!`) at the beginning will toggle the entire function, not just the first line:
```badgerql
fields event_type::str, duration::int
| filter event_type == "page_view"
| !filter
duration > 100 and
duration < 200
| stats count() by bin(1d)
```
## Types
[Section titled “Types”](#types)
In Insights, data is stored and accessed in its typed format. BadgerQL is a strongly typed language, which means it is particular about type consistency.
We currently support storing data with these types:
| Short | Long |
| ------- | ------- |
| `str` | String |
| `bool` | Boolean |
| `float` | Float |
| `int` | Integer |
### Type hinting
[Section titled “Type hinting”](#type-hinting)
Type hinting is key in BadgerQL. You indicate the expected field type using `::` and the short type name.
For example, if you know you are sending status codes as integers, you must augment your query to point to the field like:
```badgerql
fields status_code::int
```
This only gives the system a hint for where to look for the event field. It does not coerce the value into another type. If you want to convert types, use one of the [conversion expression functions](#conversion).
It’s not required to repeat type hints. If you use a field with a type hint earlier, it carries over:
```badgerql
fields status_code::int
| stats count() by status_code
```
Conflicting type hints or inaccurate hints can result in null values or errors.
We also support using these types (either through conversion or as a function result) in queries:
| Short | Long |
| ------------ | ----------------------------------- |
| `datetime` | Datetime |
| `date` | Date |
| `tzdatetime` | Datetime with timezone |
| `interval` | Relative time intervals (e.g. `1h`) |
**Note:** you can’t hint these types, as we don’t store data in these formats.
### Union types
[Section titled “Union types”](#union-types)
You may see `number` and `temporal` appear in function signatures throughout the docs. These are not types you can use directly in queries; they are shorthand for describing which concrete types a function accepts. `number` means the function works with either `int` or `float`, and `temporal` means it works with either `date` or `datetime`.
### Literal values
[Section titled “Literal values”](#literal-values)
Some function arguments don’t accept field references, only literals (e.g., `1.5`, `"hi"`). This is denoted in the type signature.
For instance, `round(duration::float, 0)` is valid with the second argument as a literal integer. `round(duration::float, precision::int)` would produce an error.
## Dates
[Section titled “Dates”](#dates)
### Creating dates
[Section titled “Creating dates”](#creating-dates)
We provide a shorthand for creating datetime literal values by wrapping the date in curly brackets `{}`:
```badgerql
fields {2023-01-01} as baseDate
```
### Casting dates
[Section titled “Casting dates”](#casting-dates)
There is no way to store native dates in Insights, so if you want to interact with a native `date` or `datetime`, you will need to cast a string column to one of the temporal types:
```badgerql
fields toDateTime(created_at::str) as created_at
| filter created_at > {2023-04-08 12:00:00}
```
### Timezones
[Section titled “Timezones”](#timezones)
All datetimes are returned in your selected timezone by default. This means that if you input a datetime, it will be automatically converted to match your preferred timezone setting.
To adjust datetimes to a specific timezone for a query, use the `toTimezone` function:
```badgerql
fields toTimezone(@ts, "America/Los_Angeles")
```
This will show the timestamp in PST, which will be denoted in the timezone information contained within the field type (`tzdatetime.PST` for this example).
## Arrays
[Section titled “Arrays”](#arrays)
Insights is primarily designed to work with simple key/value data mappings, however, it does support ingesting and querying array data in your events.
To access fields within an array, use bracket notation to specify an index. For example, `user.scopes[0].name::str` is a valid path into your event data.
### Expand function
[Section titled “Expand function”](#expand-function)
The most flexible tool for working with arrays is the `expand` BadgerQL function. `expand` unwraps array data into individual events, which you can then pipe into any other function.
For example, given events containing this data:
```json
{"id": 1, "charges": [700, 430, 200]}
{"id": 2, "charges": [100]}
```
You can expand the charges field using wildcard notation:
```badgerql
expand charges[*]::int as charge
```
This will expand each result to:
| id | charge |
| -- | ------ |
| 1 | 700 |
| 1 | 430 |
| 1 | 200 |
| 2 | 100 |
**Note:** Just like looking up a field, the path must reference a set of values. You can’t expand into an object or another array.
You can then use `stats` to group events back together after processing:
```badgerql
expand charges[*]::int as charge
| filter charge > 200
| stats sum(charge) as total_cost by id
```
Which will combine the filtered events back with summed charges:
| id | total\_cost |
| -- | ----------- |
| 1 | 1130 |
### Conditional array matching
[Section titled “Conditional array matching”](#conditional-array-matching)
Sometimes you want to know if a value within an array passes some condition. We have [special expression functions](#arrays) just for this case. For example, to find events with a specific tag:
```badgerql
filter any(tags[*]::str == "funky")
```
The `any` function also works with nested object data within an array:
```badgerql
filter any(events[*].user.email::str like "kwebster%")
```
### Performance implications
[Section titled “Performance implications”](#performance-implications)
Array support is limited in terms of performance optimizations. Where possible, consider flattening array data into separate events before sending them to Honeybadger.
## Expression functions
[Section titled “Expression functions”](#expression-functions)
Expression functions can be used in a variety of places, such as filtering data, creating fields, calculating aggregates, etc. They are used to compare fields, perform arithmetic, reformat data, and more.
### Comparison
[Section titled “Comparison”](#comparison)
The comparison operators work across `number`, `string`, `boolean`, and `datetime` types. `!=` and `<>` are equivalent operators.
`between` and `not between` are inclusive on both ends:
```badgerql
filter status_code::int between 200 and 299
```
`either` returns the first non-null value from its arguments — useful as a fallback when a field may be stored under different names:
```badgerql
fields either(name::str, full_name::str, username::str) as name
```
* `!=`
Inequality comparison. Also written `<>`.
Signature`t = number | string | boolean | datetime``t != t -> boolean`
Example
```sql
fields status_code::int != 200
```
* `<`
Signature`t = number | string | boolean | datetime``t < t -> boolean`
Example
```sql
fields status_code::int < 500
```
* `<=`
Signature`t = number | string | boolean | datetime``t <= t -> boolean`
Example
```sql
fields status_code::int <= 200
```
* `<>`
Inequality comparison. Also written `!=`.
Signature`t = number | string | boolean | datetime``t <> t -> boolean`
Example
```sql
fields status_code::int <> 200
```
* `==`
Signature`t = number | number[] | string | string[] | boolean | boolean[] | datetime | datetime[]``t == t -> boolean`
Example
```sql
fields status_code::int == 200
```
* `>`
Signature`t = number | string | boolean | datetime``t > t -> boolean`
Example
```sql
fields status_code::int > 500
```
* `>=`
Signature`t = number | string | boolean | datetime``t >= t -> boolean`
Example
```sql
fields status_code::int >= 200
```
* `between`
Signature`t = number | string | datetime``t between t and t -> boolean`
Example
```sql
filter status_code::int between 200 and 300
```
* `coalesce`
Returns the first non-null value. Synonym of `either`.
Signature`t = integer | float | string | boolean | datetime``coalesce(t, ...t) -> t`
Example
```sql
fields coalesce(name::str, full_name::str, username::str) as name
```
* `either`
Returns the first non-null value. Also accepts `coalesce`.
Signature`t = integer | float | string | boolean | datetime``either(t, ...t) -> t`
Example
```sql
fields either(name::str, full_name::str, username::str) as name
```
* `ilike`
Returns true when the search string matches
Can use these metacharacters: `%` - Matches an arbitrary amount of characters `_` - Matches single arbitrary character
The matcher is case insensitive
Signature`string ilike string -> boolean`
Example
```sql
filter email::str ilike "%compuserve%"
```
* `in`
Return true if field value is contained within the array of literal values. The field type must match value type in the array.
Signature`t = number | string | datetime``t in t[] -> boolean`
Example
```sql
filter status_code::int in [300, 301, 404]
```
* `isNotNull`
Signature`t = number | string | boolean | datetime``isNotNull(t) -> boolean`
Example
```sql
filter isNotNull(status_code::int)
```
* `isNull`
Signature`t = number | string | boolean | datetime``isNull(t) -> boolean`
* `like`
Returns true when the search string matches
Can use these metacharacters: `%` - Matches an arbitrary amount of characters `_` - Matches single arbitrary character
The string matcher is case sensitive
Signature`string like string -> boolean`
Example
```sql
filter email::str like "%compuserve%"
```
* `match`
Returns true when the regex matches
The regex uses [re2 regex syntax](https://github.com/google/re2/wiki/Syntax)
Signature`string match regex -> boolean`
Example
```sql
filter email::str match /.*compuserve.*/
```
* `not between`
Signature`t = number | string | datetime``t not between t and t -> boolean`
Example
```sql
filter status_code::int not between 300 and 400
```
* `not ilike`
Returns true when the search string does not match
Can use these metacharacters: `%` - Matches an arbitrary amount of characters `_` - Matches single arbitrary character
The matcher is case insensitive
Signature`string not ilike string -> boolean`
Example
```sql
filter email::str not ilike "%compuserve%"
```
* `not in`
Return true if field value is not contained within the array of literal values. The field type must match value type in the array.
Signature`t = number | string | datetime``t not in t[] -> boolean`
Example
```sql
filter status_code::int not in [300, 301, 404]
```
* `not like`
Returns true when the search string does not match
Can use these metacharacters: `%` - Matches an arbitrary amount of characters `_` - Matches single arbitrary character
The string matcher is case sensitive
Signature`string not like string -> boolean`
Example
```sql
filter email::str not like "%compuserve%"
```
* `not match`
Returns true when the regex does not match
The regex uses [re2 regex syntax](https://github.com/google/re2/wiki/Syntax)
Signature`string not match regex -> boolean`
Example
```sql
filter email::str not match /.*compuserve.*/
```
### Arrays
[Section titled “Arrays”](#arrays-1)
* `all`
Return true if the predicate is true for every element of an expanded array. Returns true on empty arrays (vacuous truth).
Signature`all(boolean) -> boolean`
Example
```sql
filter all(tags[*]::str != "severe")
```
```sql
filter all(coupon_ids[*]::int not in [123, 456])
```
The predicate must reference at least one expanded array (a field with `[*]`). That tells `all()` which array to iterate over.
```sql
filter all(tags[*]::str != "severe")
```
### Empty arrays
`all()` returns `true` on an empty array — there are no elements to violate the predicate. This is mathematically consistent (vacuous truth) but bites people who expect "all" to imply "at least one." If you need both "non-empty" and "all match," combine `all()` with a separate `any()` check.
### Nested object data
`[*]` works inside object paths, so you can require a property on every element of an array of objects:
```sql
filter all(events[*].status::str == "ok")
```
### Performance
Array operations don't benefit from the same indexing that scalar fields do. If you find yourself querying array data heavily, consider sending the events with the array already unrolled.
* `any`
Return true if the predicate is true for at least one element of an expanded array. Returns false on empty arrays.
Signature`any(boolean) -> boolean`
Example
```sql
filter any(tags[*]::str == "severe")
```
```sql
filter any(coupon_ids[*]::int in [123, 456])
```
The predicate must reference at least one expanded array (a field with `[*]`). That tells `any()` which array to iterate over.
```sql
filter any(tags[*]::str == "severe")
```
### Nested object data
`[*]` works inside object paths, so you can check fields on each element of an array of objects:
```sql
filter any(events[*].user.email::str like "kwebster%")
```
### Empty arrays
`any()` returns `false` on an empty array — there's nothing to match.
### Comparison vs membership predicates
The predicate inside `any()` can be anything that returns a boolean — equality, `in`/`not in`, `like`, range checks, or expressions on nested fields:
```sql
filter any(coupon_ids[*]::int in [123, 456])
filter any(prices[*]::float > 100.0)
```
You can't drop the `any()` and write `tags[*]::str in ["severe"]` directly — `in` needs a scalar on its left, and `tags[*]::str` is an array. `any()` is what unrolls the array and feeds each element into the predicate one at a time.
### Performance
Array operations don't benefit from the same indexing that scalar fields do. If you find yourself querying array data heavily, consider sending the events with the array already unrolled.
### Array
[Section titled “Array”](#array)
* `contains`
Returns true when the array contains the value. Use for simple array membership without writing `any(arr[*] == value)`.
Signature`contains(string[], string) -> boolean``contains(number[], number) -> boolean`
Example
```sql
filter contains(tags[*]::str, "severe")
```
* `dedupe`
Removes duplicate elements from an array, keeping one copy of each value. Compose with `collect` to gather distinct values per group.
Signature`t = string[] | number[] | boolean[] | datetime[]``dedupe(t) -> t`
Example
```sql
fields dedupe(tags[*]::str) as tags
```
```sql
stats dedupe(collect(user_id::str)) as users by error_class::str
```
* `reverse`
Returns the array with its element order reversed.
Signature`t = string[] | number[] | boolean[] | datetime[]``reverse(t) -> t`
Example
```sql
fields reverse(sort(scores[*]::int)) as descending_scores
```
* `sort`
Returns the array sorted ascending. This is the array function `sort(...)`, not the pipeline stage `| sort ...`; compose with `reverse` for descending order.
Signature`t = string[] | number[] | boolean[] | datetime[]``sort(t) -> t`
Example
```sql
fields sort(scores[*]::int) as sorted_scores
```
* `subarray`
Returns `length` elements of the array starting at `start`; array positions are 1-based, so `1` is the first element.
Signature`t = string[] | number[] | boolean[] | datetime[]``subarray(t, integer, integer) -> t`
Example
```sql
fields subarray(tags[*]::str, 1, 3) as first_three
```
### Logic
[Section titled “Logic”](#logic)
`if` is single-branch conditional: if the condition is true it returns the `then` value, otherwise it returns the `else` value. The `else` arm also fires when the condition evaluates to `null`.
```badgerql
fields if(status_code::int >= 500, "error", "ok") as result
```
`cond` is multi-branch: condition/value pairs are evaluated in order and the value from the first matching pair is returned. A final bare value (no preceding condition) acts as the fallback:
```badgerql
fields cond(
status_code::int >= 500, "red",
status_code::int >= 300, "yellow",
"green"
) as severity
```
* `and`
Signature`boolean and boolean -> boolean`
* `cond`
Multiple path conditional branching
The `cond()` function allows for evaluating branches (ala. `if` and `else if`) through positional arguments. Each successive pair of arguments acts as an else if, with the first true boolean passing it's result as a return."
Signature`t = string | boolean | number | datetime | date``cond(boolean, t, boolean, t, ..., t) -> t`
Example
```sql
fields cond(
status_code >= 300, "yellow",
status_code >= 500, "red",
"green"
) as status_code_color
```
* `if`
Single path conditional branching
Signature`t = string | number | boolean | temporal | interval``if(boolean, t, t) -> t`
Example
```sql
fields if(toDayOfWeek(ts) == 2, "taco", "slop") as food_day
```
* `not`
Signature`not(boolean) -> boolean`
* `or`
Signature`boolean or boolean -> boolean`
### Arithmetic
[Section titled “Arithmetic”](#arithmetic)
The standard operators (`+`, `-`, `*`, `/`, `%`) work on numbers. A few noteworthy behaviors:
* Subtracting two `datetime` values returns the difference in **seconds** as an integer: `end_ts::datetime - start_ts::datetime`
* Adding an interval to a datetime shifts it forward: `@ts + 1h`
* The second argument to `round`, `floor`, and `ceil` is the number of decimal places and must be a **literal integer** — you cannot pass a field reference. `round(duration::float, 2)` is valid; `round(duration::float, precision::int)` is not.
- `-`
Signature`number - number -> number``datetime - number -> datetime``datetime - interval -> datetime``datetime - datetime -> integer`
- `*`
Signature`number * number -> number`
- `/`
Division. Dividing by an interval converts a number of seconds — such as a datetime difference — into that unit: `(finished - started) / 1h` is hours.
Signature`t = number | interval``number / t -> float`
Example
```sql
fields (toDateTime(finished_at::str) - toDateTime(started_at::str)) / 1h as hours
```
- `%`
Signature`number % number -> number`
- `+`
Signature`number + number -> number``datetime + number -> datetime``datetime + interval -> datetime`
- `abs`
Signature`abs(number) -> number`
- `bucket`
Assign a numeric value to a bucket and return that bucket's start value. `bucket(value, width)` uses `width`-sized steps anchored at zero. `bucket(value, min, max, n)` divides `[min, max]` into `n` equal bucket slots; values outside that range return null.
Signature`bucket(number, literal number) -> number``bucket(number, literal number, literal number, literal integer) -> number`
Example
```sql
stats count() as ct by bucket(duration::int, 250) as ms
```
```sql
stats count() as ct by bucket(duration::int, 0, 5000, 16) as ms
```
The width form is the numeric counterpart of `bin()` for time: `bucket(duration::int, 100)` maps `250` to `200`, the start of its 100-wide bucket. Negative values land on the same grid (`-50` maps to `-100`).
The bounded form fixes the range and bucket count instead: the width is `(max - min) / n`, so `bucket(duration::int, 0, 1000, 4)` creates starts at `0`, `250`, `500`, and `750`. `100` maps to `0`, `999` maps to `750`, and a value exactly equal to `max` also maps to the last bucket. Anything outside `[min, max]` returns null; filter the range first if you do not want an out-of-range null group.
### Histograms
`bucket()` only assigns rows that already exist. Group by the bucket and count, then `fill` to make empty buckets explicit. The fill grid is inferred from the bucket — its width becomes the step, and the bounded form's min/max become from/to:
```sql
stats count() as ct by bucket(duration::int, 0, 2000, 20) as ms
| fill ms
| sort ms asc
```
### Why explicit parameters
The width (or bounds and count) are part of the query, so the bucket grid is stable — the same query yesterday and today produces comparable buckets, and outliers can't warp the ranges.
- `ceil`
Signature`ceil(number, literal integer) -> float`
- `exp`
Signature`exp(number) -> float`
- `floor`
Signature`floor(number, literal integer) -> float`
- `intDiv`
Divide two numbers and return the integer quotient. Use `/` when you want a floating-point result.
Signature`intDiv(number, number) -> integer`
- `log`
Signature`log(number) -> float`
- `log10`
Signature`log10(number) -> float`
- `log2`
Signature`log2(number) -> float`
- `pow`
Signature`pow(number, number) -> float`
- `round`
Signature`round(number, literal integer) -> float`
- `sign`
Returns -1 for negative numbers, 0 for zero, and 1 for positive numbers.
Signature`sign(number) -> integer`
- `sqrt`
Signature`sqrt(number) -> float`
- `truncate`
Drop digits past the given number of decimal places without rounding. This is different from `floor`, which always rounds down.
Signature`truncate(number, literal integer) -> float`
### Conversion
[Section titled “Conversion”](#conversion)
A few things worth knowing:
* `toDateTime` from a string uses best-effort parsing, so it handles a wide variety of date formats (ISO 8601, RFC 2822, etc.) without needing an exact format string.
* `toUnix` returns **milliseconds** since the Unix epoch, not seconds.
* `toDate` strips the time component from a datetime and returns a date-only value.
- `toDate`
Signature`t = string | datetime``toDate(t) -> date`
- `toDateTime`
Signature`t = number | date | string | temporal``toDateTime(t) -> datetime`
- `toFloat`
Signature`toFloat(any) -> float`
- `toInt`
Signature`toInt(any) -> integer`
- `toString`
Signature`toString(any) -> string`
- `toUnix`
Signature`toUnix(datetime) -> integer`
### Dates
[Section titled “Dates”](#dates-1)
`now()` returns the current datetime in the query’s configured timezone.
`toStartOf` and `toEndOf` are lower-level alternatives to `bin()` when you need the start or end of an interval boundary rather than grouping:
```badgerql
fields toStartOf(1w) as week_start
```
```badgerql
fields toEndOf(1d) as end_of_day
```
`toDayOfWeek` returns 1–7 where 1 = Monday and 7 = Sunday.
See also the [Dates](#dates) section above for creating and casting date literals.
* `bin`
Round a datetime down to the nearest interval boundary. Most often used in `stats ... by bin(...)` to bucket events into a time series.
Signature``bin(datetime = `@ts`) -> datetime````bin(interval, datetime = `@ts`) -> datetime``
Example
```sql
fields bin(1w) as beginning_of_week
```
```sql
stats count() by bin(1h, toDateTime(user.created_at::str))
```
### Choosing the interval
If you pass an interval, that's the bin size:
```sql
stats count() by bin(1h)
```
If you omit the interval, `bin()` picks a size based on the query's time range — small bins for short ranges, larger bins for longer ones. The exact thresholds aren't fixed, so pass an explicit interval if you need a specific size.
### Choosing the field
By default `bin()` operates on the event timestamp (`@ts`). Pass a datetime field as the second argument to bin against something else:
```sql
stats count() by bin(1d, toDateTime(user.created_at::str))
```
### Filling gaps
Bins with no matching events don't appear in the result. To produce a continuous series, pipe through `fill` — the step is inferred from the bin:
```sql
stats count() by bin(1h) as t
| fill t
```
* `formatDate`
Render a datetime as a string using a format pattern. Defaults to the event timestamp (`@ts`) if no datetime is given.
Signature``formatDate(literal string, datetime = `@ts`) -> string``
Example
```sql
fields formatDate("%Y-%m-%d") as day
```
```sql
stats count() by formatDate("%a", @ts) as weekday
```
### Date tokens
| | | |
| ---- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `%j` | day of the year (001-366) | 002 |
| `%d` | day of the month, zero-padded (01-31) | 02 |
| `%e` | day of the month, space-padded (1-31) | 2 |
| | | |
| `%V` | ISO 8601 week number (01-53) | 01 |
| `%w` | weekday as a integer number with Sunday as 0 (0-6) | 2 |
| `%u` | ISO 8601 weekday as number with Monday as 1 (1-7) | 2 |
| `%a` | abbreviated weekday name (Mon-Sun) | Mon |
| `%W` | full weekday name (Monday-Sunday) | Monday |
| | | |
| `%m` | month as an integer number (01-12) | 01 |
| `%M` | full month name (January-December) | January |
| `%b` | abbreviated month name (Jan-Dec) | Jan |
| `%Q` | Quarter (1-4) | 1 |
| | | |
| `%y` | Year, last two digits (00-99) | 18 |
| `%Y` | Year | 2018 |
| `%C` | year divided by 100 and truncated to integer (00-99) | 20 |
| `%g` | two-digit year format, aligned to ISO 8601, abbreviated from four-digit notation | 18 |
| `%G` | four-digit year format for ISO week number, calculated from the week-based year defined by the ISO 8601 standard, normally useful only with %V | 2018 |
| | | |
| `%D` | Short MM/DD/YY date, equivalent to %m/%d/%y | 01/02/18 |
| `%F` | short YYYY-MM-DD date, equivalent to %Y-%m-%d | 2018-01-02 |
### Time tokens
| | | |
| ---- | ------------------------------------------------------- | -------- |
| `%s` | second (00-59) | 44 |
| `%S` | second (00-59) | 44 |
| `%f` | fractional second | 1234560 |
| | | |
| `%i` | minute (00-59) | 33 |
| | | |
| `%h` | hour in 12h format (01-12) | 09 |
| `%I` | hour in 12h format (01-12) | 10 |
| `%H` | hour in 24h format (00-23) | 22 |
| `%l` | hour in 12h format (01-12) | 09 |
| `%k` | hour in 24h format (00-23) | 22 |
| `%r` | 12-hour HH:MM AM/PM time, equivalent to %H:%i %p | 10:30 PM |
| `%R` | 24-hour HH:MM time, equivalent to %H:%i | 22:33 |
| | | |
| `%p` | AM or PM designation | PM |
| `%T` | ISO 8601 time format (HH:MM:SS), equivalent to %H:%i:%S | 22:33:44 |
| `%z` | Time offset from UTC as +HHMM or -HHMM | -0500 |
### Other tokens
| | | |
| ---- | ------------------------ | - |
| `%n` | new-line character | |
| `%t` | horizontal-tab character | |
| `%%` | a % sign | % |
* `now`
Signature`now() -> datetime`
* `toDay`
Returns the day of month (1-31) for the supplied datetime.
Signature`toDay(datetime) -> integer`
* `toDayOfWeek`
Returns the number of the day in a week (1-7, 1 = monday) for the supplied datetime.
Signature`toDayOfWeek(datetime) -> integer`
* `toDayOfYear`
Returns the day of the year (1-366) from a datetime.
Signature`toDayOfYear(datetime) -> integer`
* `toEndOf`
Signature``toEndOf(interval, datetime = `@ts`) -> datetime``
* `toHour`
Returns the 24-hour number (0-23) for the supplied datetime.
Signature`toHour(datetime) -> integer`
* `toMinute`
Returns the minute of the hour (0-59) from a datetime.
Signature`toMinute(datetime) -> integer`
* `toMonth`
Returns the month number (1-12) from a datetime.
Signature`toMonth(datetime) -> integer`
* `toSecond`
Returns the second of the minute (0-59) from a datetime.
Signature`toSecond(datetime) -> integer`
* `toStartOf`
Signature``toStartOf(interval, datetime = `@ts`) -> datetime``
* `toTimezone`
Convert datetimes to a specific timezone.
**Note:** This does not explicitly embed the timezone into the datetime, but updates the type to reflect the selected timezone (tzdatetime).
Signature`toTimezone(datetime, literal string) -> datetime`
* `toYear`
Signature`toYear(datetime) -> integer`
### URL
[Section titled “URL”](#url)
* `urlBaseDomain`
Extracts the registrable/base domain from a URL's hostname, so subdomains can be grouped together.
Signature`urlBaseDomain(string) -> string`
* `urlDomain`
Extracts the hostname from a URL.
Signature`urlDomain(string) -> string`
* `urlParameter`
Parse out value from valid URL query string
Signature`urlParameter(string, literal string) -> string`
Example
```sql
fields urlParameter(url::str, "user_id") as user_id_param
```
* `urlPath`
Extracts the path from a URL. Example: `/hot/goss.html` The path does not include the query string.
Signature`urlPath(string) -> string`
* `urlPort`
Extracts the explicit port from a URL, or returns 0 when the URL does not include one.
Signature`urlPort(string) -> integer`
* `urlProtocol`
Extracts the URL protocol without `://`, for example `https`.
Signature`urlProtocol(string) -> string`
* `urlQueryString`
Extracts the query string from a URL without the leading `?`, for example `page=2&sort=desc`.
Signature`urlQueryString(string) -> string`
### Network
[Section titled “Network”](#network)
* `inCIDR`
Returns true when the IP address falls within the CIDR range. Works for IPv4 and IPv6.
The address must be a valid IP string. Malformed strings cause a query error.
Signature`inCIDR(string, literal string) -> boolean`
Example
```sql
filter inCIDR(client_ip::str, "10.0.0.0/8")
```
### Hashing
[Section titled “Hashing”](#hashing)
`cityHash64` and `xxHash64` are fast, non-cryptographic hashes for bucketing, sampling, or stable grouping. `MD5` and `SHA256` return hex strings for comparing against pre-hashed identifiers.
* `cityHash64`
Returns a fast, deterministic 64-bit hash of the value. Not cryptographic; use for bucketing, sampling, or stable grouping.
Signature`cityHash64(any) -> integer`
* `MD5`
Returns the MD5 hash of a string as lowercase hexadecimal text. Useful for comparing against pre-hashed identifiers.
Signature`MD5(string) -> string`
* `SHA256`
Returns the SHA-256 hash of a string as lowercase hexadecimal text. Useful for comparing against pre-hashed identifiers.
Signature`SHA256(string) -> string`
* `xxHash64`
Returns a fast, deterministic 64-bit hash of the value. Not cryptographic; use for bucketing, sampling, or stable grouping.
Signature`xxHash64(any) -> integer`
### JSON
[Section titled “JSON”](#json)
* `isValidJSON`
Returns true when the string parses as JSON.
Signature`isValidJSON(string) -> boolean`
Example
```sql
filter isValidJSON(payload::str)
```
* `json`
Extract a scalar value from a JSON string using a JSONPath expression. Returns null if the path doesn't resolve to a scalar — arrays and objects are not valid targets.
Signature`json(string, literal string) -> string`
Example
```sql
fields json(user_config::str, "$.login_info.last_login") as last_logged_in
```
### Path syntax
Paths follow [JSONPath](https://www.ietf.org/archive/id/draft-goessner-dispatch-jsonpath-00.html). Common patterns:
| Path | Selects |
| ---------------------- | ------------------------------------ |
| `$.foo` | the value at key `foo` |
| `$.foo.bar` | nested key `bar` under `foo` |
| `$.items[0]` | the first element of an array |
| `$.items[-1]` | the last element of an array |
| `$['key with spaces']` | a key with non-identifier characters |
### Type handling
`json()` returns the value as a string. To use it as a number or datetime, cast it with the appropriate conversion function:
```sql
fields toInt(json(payload::str, "$.user.id")) as user_id
```
### When it returns null
* The path doesn't resolve (key missing, index out of range)
* The path resolves to an object or array — only scalar values come back
* The input isn't valid JSON
### Recommendation
We support `json()` for ad-hoc digging into payloads, but querying it at scale is slower than querying real fields. If you find yourself reaching for it often on the same paths, send those values as top-level event fields instead.
### String
[Section titled “String”](#string)
`toHumanString` supports five format types: `"number"` (default), `"bytes"`, `"short"`, `"milliseconds"`, and `"microseconds"` for microsecond-precision duration fields.
`startsWith` is a convenience wrapper around `like` — it is case-sensitive and does not accept wildcards in the match string.
* `concat`
Signature`concat(string, string...) -> string`
* `editDistance`
Returns the number of single-character edits (insertions, deletions, substitutions) needed to transform one string into the other. Lower values are more similar.
Signature`editDistance(string, string) -> integer`
Example
```sql
filter editDistance(error_message::str, "connection timed out") < 5
```
* `endsWith`
Returns true when the first string ends with the second string.
Signature`endsWith(string, string) -> boolean`
Example
```sql
filter endsWith(file::str, ".rb")
```
* `length`
Returns the number of characters in a string, or the number of elements in an array.
Signature`t = string | string[] | number[] | boolean[] | datetime[]``length(t) -> integer`
* `lowercase`
Signature`lowercase(string) -> string`
* `position`
Returns the 1-based position of the first occurrence of the search string, or 0 when it is not found.
Signature`position(string, string) -> integer`
Example
```sql
fields position(message::str, "timeout") as timeout_at
```
* `replace`
Replace all matches of a substring or regex pattern with another string.
Signature`t = string | regex``replace(string, t, string) -> string`
Example
```sql
fields replace(controller::str, /Controller/, "") as controller
```
* `replaceFirst`
Replace the first match of a substring or regex pattern with another string.
Signature`t = string | regex``replaceFirst(string, t, string) -> string`
Example
```sql
fields replaceFirst(controller::str, /Controller/, "") as controller
```
* `similarity`
Returns a 0-1 similarity score for two strings: 1 means identical, 0 means no similarity. Easier to threshold than `editDistance` when string lengths vary.
Signature`similarity(string, string) -> float`
Example
```sql
filter similarity(error_message::str, "connection timed out") > 0.9
```
* `split`
Splits a string into an array of substrings around a literal separator. Null input returns an empty array.
Signature`split(string, literal string) -> string[]`
Example
```sql
fields split(tags::str, ",") as tag_list
```
* `startsWith`
Signature`startsWith(string, string) -> boolean`
* `substring`
Signature`substring(string, integer, integer) -> string`
Example
```sql
fields substring(token::str, 1, 3) as token_type
```
* `toHumanString`
Transform a number into a human-readable string. Picks units, separators, and rounding based on the format type. Defaults to `"number"` (comma-separated) if no type is given.
Signature`toHumanString(number, string = "number") -> string`
Example
```sql
fields toHumanString(duration::int, "milliseconds")
```
```sql
fields toHumanString(@size, "bytes")
```
### Format types
| Type | Output | Example input → output |
| ---------------- | ------------------------- | ---------------------------- |
| `"number"` | comma-separated digits | `1234567` → `"1,234,567"` |
| `"short"` | rounded shorthand | `1234567` → `"1.23 million"` |
| `"bytes"` | rounded binary size | `105906176` → `"101.0 MiB"` |
| `"milliseconds"` | duration starting from ms | `1500` → `"1.5s"` |
| `"microseconds"` | duration starting from µs | `1500` → `"1.5ms"` |
### Common usage
```sql
stats avg(duration::int) as avg_ms
| fields toHumanString(avg_ms, "milliseconds") as avg
```
```sql
stats sum(@size) as total
| fields toHumanString(total, "bytes") as total_size
```
Mostly useful for charting and table output. For computation, keep the raw number and only format at the end.
* `trim`
Signature`trim(string) -> string`
* `uppercase`
Signature`uppercase(string) -> string`
### Aggregate
[Section titled “Aggregate”](#aggregate)
Aggregate functions are only valid inside a `stats` call.
`count()` with no argument counts all events. Passing a boolean expression counts only events where the expression is true. Passing a field name counts only non-null occurrences of that field:
```badgerql
stats count() -- all events
stats count(status_code::int >= 500) -- events with 5xx status
stats count(user_id::str) -- events where user_id is not null
```
`first` and `last` return the first or last value seen within the group. If the data is not sorted before `stats`, the result is non-deterministic. Pipe through `sort` first if order matters.
`percentile` is an approximated result.
* `apdex`
Returns the Application Performance Index (Apdex) score, which measures user satisfaction with response time.
Signature`apdex(number, number) -> float`
Example
```sql
stats apdex(duration::int, 500) as apdex_score
```
Apdex scores a sample of response times against a target threshold `T`. Each request counts as:
* **Satisfied** (1.0) if it completed in `T` or less
* **Tolerating** (0.5) if it completed between `T` and `4T`
* **Frustrated** (0) if it took longer than `4T`
The score is the average — so 1.0 means every request was satisfied, 0 means every request was frustrated.
```sql
stats apdex(duration::int, 500) as score
```
### Picking a threshold
`T` should be the response time at which a typical user starts to notice latency. Common starting points:
* User-facing web requests: 200–500ms
* API endpoints: 100–300ms
* Background jobs: depends on the job — pick something tied to user expectations
### Reading the score
Rough rule of thumb:
| Score | Reading |
| ----------- | ------------ |
| ≥ 0.94 | Excellent |
| 0.85 – 0.94 | Good |
| 0.70 – 0.85 | Fair |
| 0.50 – 0.70 | Poor |
| < 0.50 | Unacceptable |
These bands aren't a Honeybadger-specific standard — they come from the Apdex specification.
* `apdexIf`
Returns the Apdex score computed only over events where the predicate is true.
The predicate restricts the whole calculation — satisfied and tolerating counts as well as the total — so the score reads as "the apdex of this slice of events." See `apdex` for how the score itself works.
Signature`apdexIf(number, number, boolean) -> float`
Example
```sql
stats apdexIf(duration::int, 500, route::str == "/checkout") as checkout_apdex
```
* `avg`
Signature`avg(number) -> number`
* `avgIf`
Average a numeric value across events where the predicate is true.
Signature`avgIf(number, boolean) -> number`
Example
```sql
stats avgIf(duration::int, route::str == "/checkout") as checkout_avg
```
* `avgWeighted`
Returns a weighted average. Values with larger weights count more, which is useful when averaging pre-aggregated rows such as per-route latency weighted by request count.
Signature`avgWeighted(number, number) -> float`
Example
```sql
stats avgWeighted(avg_latency::float, request_count::int) as typical_latency
```
* `collect`
Collects the values from each group into an array. Compose with `dedupe` when you want distinct values.
Signature`t = string | integer | float | boolean | datetime``collect(t) -> t[]`
Example
```sql
stats dedupe(collect(user_id::str)) as users by error_class::str
```
* `corr`
Returns the correlation coefficient between two numeric expressions: -1 is inverse correlation, 0 is no linear correlation, and 1 is direct correlation.
Signature`corr(number, number) -> float`
Example
```sql
stats corr(memory::float, response_time::float) as memory_vs_latency
```
* `count`
Return the total counts of all results.
The count can be affected by supplying a boolean expression argument. If given a field, it will implicitly count non-null occurrences.
Signature`count() -> integer``count(boolean) -> integer``count(number) -> integer``count(string) -> integer`
Example
```sql
stats count()
```
```sql
stats count(status_code::int < 500)
```
* `countIf`
Count events where the predicate is true.
Signature`countIf(boolean) -> integer`
Example
```sql
stats countIf(status_code::int >= 500) as errors
```
* `first`
Returns the first encountered value. Results could be random if the source is not sorted.
Signature`t = string | number | boolean | datetime``first(t) -> t`
Example
```sql
stats first(user_name::str) by error_class::str
```
* `firstIf`
Returns the first encountered value among events where the predicate is true. Use `pickMin(value, @ts)` when you need deterministic earliest-by-time semantics.
Signature`t = string | number | boolean | datetime``firstIf(t, boolean) -> t`
Example
```sql
sort @ts asc | stats firstIf(message::str, level::str == "error") as first_error by host::str
```
* `last`
Returns the last encountered value. Results could be random if the source is not sorted.
Signature`t = string | number | boolean | datetime``last(t) -> t`
Example
```sql
stats last(severity::str) by error_class::str
```
* `lastIf`
Returns the last encountered value among events where the predicate is true. Use `pickMax(value, @ts)` when you need deterministic latest-by-time semantics.
Signature`t = string | number | boolean | datetime``lastIf(t, boolean) -> t`
Example
```sql
sort @ts asc | stats lastIf(message::str, level::str == "error") as last_error by host::str
```
* `max`
Signature`t = string | number | datetime``max(t) -> t`
* `maxIf`
Return the maximum value across events where the predicate is true.
Signature`t = string | number | datetime``maxIf(t, boolean) -> t`
Example
```sql
stats maxIf(duration::int, status_code::int >= 500) as slowest_error
```
* `median`
Returns the median value. Equivalent to `percentile(50, value)` and approximated the same way.
Signature`median(number) -> number`
* `min`
Signature`t = string | number | datetime``min(t) -> t`
* `minIf`
Return the minimum value across events where the predicate is true.
Signature`t = string | number | datetime``minIf(t, boolean) -> t`
Example
```sql
stats minIf(duration::int, status_code::int >= 500) as fastest_error
```
* `percentile`
Calculate the percentile.
This is an approximated result.
Signature`percentile(literal number, number) -> number`
Example
```sql
stats percentile(90, duration::int)
```
* `percentileIf`
Calculate a percentile across events where the predicate is true.
This is an approximated result.
Signature`percentileIf(literal number, number, boolean) -> number`
Example
```sql
stats percentileIf(95, duration::int, status_code::int < 500) as p95_ok
```
* `pickMax`
Returns the first argument from the row where the second argument is largest. `pickMax(error_message::str, @ts)` returns the most recent error message in each group.
Signature`t = string | integer | float | boolean | datetime``pickMax(t, any) -> t`
Example
```sql
stats pickMax(error_message::str, @ts) as latest_error by error_class::str
```
* `pickMin`
Returns the first argument from the row where the second argument is smallest. `pickMin(user_id::str, duration::int)` returns the user from the fastest request in each group.
Signature`t = string | integer | float | boolean | datetime``pickMin(t, any) -> t`
Example
```sql
stats pickMin(user_id::str, duration::int) as fastest_user by controller::str
```
* `rate`
Convert an aggregate into a rate by dividing it by the width of the query's `bin()` group. Defaults to a per-second rate; pass an interval to get a rate per minute, per hour, etc.
Signature`rate(number) -> float``rate(number, interval) -> float`
Example
```sql
stats rate(count()) as rps by bin(1m) as t
```
```sql
stats rate(sum(bytes::int)) as bps by bin() as t
```
```sql
stats rate(count(), 1m) as rpm by bin(1h) as t
```
### Following the bin
The divisor is the width of the query's `bin()`. That includes auto-sized `bin()` — when the bin width changes with the query window, the divisor changes with it, and the result keeps the same unit:
```sql
stats rate(count()) as rps by bin() as t
```
### Choosing the interval
The default is per second — the universal observability idiom (RPS, BPS, errors/sec). Pass an interval as the second argument for other units; the bin size doesn't have to match:
```sql
stats rate(count(), 1m) as rpm by bin(1h) as t
```
### Composing
Rates are plain numbers, so they compose with arithmetic — two rates over the same bin make a unitless ratio:
```sql
stats (rate(countIf(status::int >= 500)) / rate(count())) as error_rate by bin(1m) as t
```
### Restrictions
* Requires exactly one `bin()` group in the same stats stage (directly or via a renamed field).
* The argument must be an aggregate. Rates are most natural over `count`/`sum`-style aggregates; `rate(min(x))` is computable but rarely what you want.
* Month and year bins or intervals are rejected — they have no fixed second count, so use a fixed-period interval like `30d`.
* `stddev`
Returns the sample standard deviation of the numeric values. Pair with `avg` to see how spread out a metric is.
Signature`stddev(number) -> float`
* `sum`
Signature`sum(number) -> number`
* `sumIf`
Sum a numeric value across events where the predicate is true.
Signature`sumIf(number, boolean) -> number`
Example
```sql
stats sumIf(amount::float, status::str == "paid") as paid_total
```
* `unique`
Count all unique values
Signature`t = string | number | datetime``unique(t) -> integer`
Example
```sql
stats unique(concat(controller::str, action::str))
```
* `uniqueIf`
Count distinct values among events where the predicate is true.
Signature`t = string | number | datetime``uniqueIf(t, boolean) -> integer`
Example
```sql
stats uniqueIf(user_id::str, event_type::str == "purchase") as purchasers
```
* `variance`
Returns the sample variance of the numeric values. Variance is the square of standard deviation.
Signature`variance(number) -> float`
### Grouping
[Section titled “Grouping”](#grouping-1)
* `top`
Select the top N values of a field. By default, values are ranked by frequency. An optional third argument ranks values by an aggregate instead, such as `max`, `sum`, or `avg`.
`top()` is context-aware: it caps groups, filters by membership, or returns an array depending on where it appears. Useful for high-cardinality fields like controllers, endpoints, queues, or workers.
Signature`t = string | number``top(literal integer, t, any = null) -> t[] | t`
Example
```sql
stats count() by top(10, controller::str)
```
```sql
filter controller::str in top(5, controller::str)
```
```sql
stats top(10, controller::str) by env::str
```
### In a stats group
Caps the group to the top N values, dropping the rest. By default, "top" means most frequent. The default ranking is approximate.
```sql
stats count() by top(10, controller::str)
```
Pass an `order_by` aggregate as the third argument to rank by something other than frequency. This switches to an exact ranking — slower than the default, but deterministic.
```sql
stats count() by top(10, controller::str, max(duration::float))
```
Combine with `bin()` to chart the top N series over time:
```sql
stats avg(duration::float) by top(10, controller::str), bin()
```
Group-position `top()` may be wrapped in another expression (e.g. `lower(top(5, controller::str))`). The ranking matches the wrapped value so the result lines up with the group key.
### In a filter
Tests membership against the top N values. Use `in` to keep matching events or `not in` to exclude them.
```sql
filter controller::str in top(5, controller::str)
```
The check runs against raw events when used in a pre-stats filter, and against grouped results when used in a post-stats filter. In practice, `filter controller::str in top(5, controller::str) | stats count() by bin()` selects the top 5 controllers from the source events first, then charts only those events over time.
### As a stats aggregate
Returns the top N values as an array.
```sql
stats top(10, controller::str) by env::str
```
Aggregate-position `top()` does not accept an `order_by` argument.
Given an expanded array field, it ranks the array's elements and still returns a flat array. This counts every element across all events, so it does not multiply rows the way `expand` does.
```sql
stats top(3, tags[*]::str) as top_tags by fault_id::int
```
### Restrictions
* `n` must be a positive integer literal — not a field reference.
* `top()` is not allowed inside an `or` condition.
* In a filter, `top()` must be the right-hand side of `in` or `not in`. Other filter shapes (e.g. equality) are rejected.
# Ship your CloudWatch Logs to Honeybadger Insights
> Here's how to ship your logs from CloudWatch Logs to Honeybadger Insights.
Ingesting logs from CloudWatch Logs requires setting up a [Data Firehose](https://aws.amazon.com/firehose/) stream with a [HTTP Endpoint destination](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-http) that sends events to our API. Once you create [subscription filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample) for the desired log groups, log data from those groups will start flowing into Insights.
The easiest way to set this up is to use our [CloudFormation template](https://honeybadger-docs-assets.s3.amazonaws.com/insights-cloudformation-stack.yml) to create a CloudFormation stack in your AWS account. It will prompt you to enter your Honeybadger API key and the name of a log group that you want to connect to Data Firehose. You can quickly [launch this template in your AWS account](https://console.aws.amazon.com/cloudformation/home#/stacks/new?stackName=honeybadger-insights\&templateURL=https://honeybadger-docs-assets.s3.amazonaws.com/insights-cloudformation-stack.yml) and then create additional log group subscriptions for other log groups you wish to monitor.
If you set up the Data Firehose stream manually, choose HTTP Endpoint as the destination and use the following URL as the HTTP Endpoint URL in the destination settings:
```plaintext
https://api.honeybadger.io/v1/data-firehose-events?api_key=PROJECT_API_KEY
```
## Setting default fields with a query parameter
[Section titled “Setting default fields with a query parameter”](#setting-default-fields-with-a-query-parameter)
Events from this endpoint are built from the CloudWatch Logs record, so they always have the same shape: a `ts`, a `message`, and the `logGroup` and `logStream` the record came from. If you want more than that — the environment, the region, the name of the app — you can add a `defaults` query parameter to the HTTP Endpoint URL containing a URL-encoded JSON object, and its fields will be merged into every event the stream delivers:
```plaintext
https://api.honeybadger.io/v1/data-firehose-events?api_key=PROJECT_API_KEY&defaults={"environment":"production","region":"us-east-1"}
```
With that URL, an event that would otherwise be stored as:
```json
{"ts": "2023-08-31T09:19:30.000Z", "logGroup": "/aws/lambda/checkout", "logStream": "2023/08/31/[$LATEST]abc123", "message": "This is a log line"}
```
…is stored as:
```json
{"ts": "2023-08-31T09:19:30.000Z", "logGroup": "/aws/lambda/checkout", "logStream": "2023/08/31/[$LATEST]abc123", "message": "This is a log line", "environment": "production", "region": "us-east-1"}
```
Because the parameter lives on the destination URL, each Data Firehose stream can carry its own metadata — a useful way to tag events by environment or account when you’re shipping logs from more than one place, without running a transformation Lambda to rewrite the payloads.
The `defaults` parameter has a few restrictions:
* It must be a flat JSON object; values must be strings, numbers, or booleans.
* The keys `event_type` and `ts` are reserved and will be ignored.
* It’s limited to 16 keys and 2kB (URL-decoded).
* Fields we build from the log record always win — a default named `message` or `logGroup` won’t overwrite the real one.
An invalid `defaults` parameter never causes the delivery to fail: entries that break the rules above are dropped (an unparseable or oversized parameter is ignored entirely), and the events are ingested without them. Likewise, if merging the defaults would push an event past the 100kB per-event size limit, we drop the defaults for that event rather than the event itself.
# Ship your Crunchy Bridge logs to Honeybadger Insights
> Ship Postgres logs from Crunchy Bridge to Honeybadger Insights.
You can have Crunchy Bridge ship the logs from your Postgres clusters by following their [setup instructions](https://docs.crunchybridge.com/how-to/logging).
Use the following values for the logging destination:
| Field | Value |
| -------- | --------------------------------------------------------------------------------------------------------- |
| Host | in.honeybadger.io |
| Port | 6514 |
| Template | `<$PRI>1 $ISODATE $HOST $PROGRAM $PID ${MSGID:--} [honeybadger@61642 api_key=\"PROJECT_API_KEY\"] $MSG\n` |
You can choose to add additional key/value data to the structured data section of the template. E.g., if you want to add an environment field to the payload, you can specify it after the API key in the template:
```plaintext
<$PRI>1 $ISODATE $HOST $PROGRAM $PID ${MSGID:--} [honeybadger@61642 api_key=\"PROJECT_API_KEY\" environment=\"production\"] $MSG\n
```
# Ship your Docker container logs to Honeybadger Insights
> Here's how to use Vector to collect Docker container logs and send them to Honeybadger Insights.
You can use [Vector](https://vector.dev) with its `docker_logs` source to collect logs from your Docker containers and send them to Honeybadger Insights. This example collects logs from all running containers:
```yaml
# Put this in vector.yaml
sources:
docker:
type: "docker_logs"
transforms:
enrich_docker:
type: "remap"
inputs: ["docker"]
source: |
# Try to parse JSON log messages
payload, err = parse_json(string!(.message))
if err == null {
.payload = payload
del(.message)
}
sinks:
honeybadger_events:
type: "http"
inputs: ["enrich_docker"]
uri: "https://api.honeybadger.io/v1/events"
request:
headers:
X-API-Key: "PROJECT_API_KEY"
encoding:
codec: "json"
framing:
method: "newline_delimited"
```
To run Vector with Docker and collect logs from other containers, you need to mount the Docker socket. Here’s a Docker Compose configuration:
```yaml
services:
vector:
image: timberio/vector:latest-alpine
volumes:
- "./vector.yaml:/etc/vector/vector.yaml:ro"
- "/var/run/docker.sock:/var/run/docker.sock:ro"
# Example app container whose logs will be collected
app:
image: your-app:latest
labels:
vector.enable: "true"
```
You can filter which containers Vector collects logs from using labels. Update the source configuration to only collect logs from containers with a specific label:
```yaml
sources:
docker:
type: "docker_logs"
include_labels:
- "vector.enable=true"
```
# Send logs and events from Elixir apps to Honeybadger Insights
> Here's how to integrate your Elixir apps with Honeybadger Insights.
When enabled, Honeybadger [automatically instruments your Elixir/Phoenix application](/lib/elixir/insights/automatic-instrumentation/) to send application events to Honeybadger Insights. This is the easiest way to get started with Insights and logging. To get started, enable Insights in your app configuration:
```elixir
config :honeybadger,
insights_enabled: true
```
See our [automatic instrumentation](/lib/elixir/insights/automatic-instrumentation/) guide to learn more. You can also [add extra context data](/lib/elixir/insights/event-context/) to events, [filter events](/lib/elixir/insights/filtering-events/) to remove PII, and [sample events](/lib/elixir/insights/sampling-events/) to reduce the amount of data sent to Honeybadger.
## Sending custom events
[Section titled “Sending custom events”](#sending-custom-events)
You can send custom events to Honeybadger Insights with the `Honeybadger.event/1` and `Honeybadger.event/2` functions. For example:
```elixir
Honeybadger.event(%{
event_type: "user_created",
user: user.id
})
Honeybadger.event("project_deleted", %{
project: project.name
})
```
## Sending logs from your infrastructure
[Section titled “Sending logs from your infrastructure”](#sending-logs-from-your-infrastructure)
Honeybadger isn’t just for errors and application data! You can use our [syslog](/guides/insights/integrations/systemd/), [Vector](/guides/insights/integrations/log-files/), or [PaaS integrations](/guides/insights/#adding-data-from-other-sources) to send additional data from your infrastructure to [Honeybadger Insights](/guides/insights/), where you can query, visualize, and analyze all of your production data in one place.
# Ship your Fly.io logs to Honeybadger Insights
> Here's how to ship your logs from Fly.io to Honeybadger Insights.
Use [Fly.io’s log shipper app](https://github.com/superfly/fly-log-shipper) to ship logs from your apps hosted by Fly.io. First, create a new app config:
```shell
# Make a directory for your log shipper app
mkdir logshipper
cd logshipper
# Create the app but don't deploy just yet
fly launch --no-deploy --image ghcr.io/superfly/fly-log-shipper:latest
# Set some secrets. Setting HONEYBADGER_API_KEY enables the shipping of logs to your Honeybadger project.
fly secrets set ORG=personal # The org you chose when running "fly launch"
fly secrets set ACCESS_TOKEN=$(fly auth token)
fly secrets set HONEYBADGER_API_KEY=PROJECT_API_KEY
```
Edit the generated `fly.toml` file, replacing the `[http_service]` section with this:
```toml
[[services]]
http_checks = []
internal_port = 8686
```
Then deploy the app:
```shell
fly deploy
```
Once that’s done, you should see logs from your apps flowing into Insights. See the [Fly.io docs](https://fly.io/docs/going-to-production/monitoring/exporting-logs/) for more information about using the log shipper app.
# Ship your Heroku logs to Honeybadger Insights
> Here's how to ship your logs from Heroku to Honeybadger Insights.
To get your Heroku logs into Insights, create a new log drain for your Heroku app using an API key displayed on the API keys tab of the project settings page:
```bash
heroku drains:add "https://logplex.honeybadger.io/v1/events?api_key=PROJECT_API_KEY"
```
You can optionally add the `env` parameter to the log drain endpoint. If you do so, each payload recorded from Logplex will have a field named `environment` added to it. You can then add a filter for the desired environment to your queries, like `filter environment::str == 'production'`.
```bash
heroku drains:add https://logplex.honeybadger.io/v1/events?api_key=PROJECT_API_KEY&env=production
```
# Host metrics
> Monitor CPU, memory, and disk usage on your servers with Honeybadger Insights.
Track your infrastructure’s health by sending host metrics to [Honeybadger Insights](/guides/insights/). Monitor CPU usage, memory consumption, and disk space alongside your application errors and logs.
## Using the Honeybadger CLI
[Section titled “Using the Honeybadger CLI”](#using-the-honeybadger-cli)
The easiest way to collect host metrics is with the [Honeybadger CLI](/resources/cli/). Download a prebuilt binary from the [GitHub releases page](https://github.com/honeybadger-io/cli/releases), or install with Go:
```shell
go install github.com/honeybadger-io/cli@latest
```
See the [CLI installation guide](/resources/cli/#installation) for other options, including Homebrew.
Start the metrics agent with your project API key:
```shell
hb agent --api-key PROJECT_API_KEY
```
The agent collects CPU, memory, and disk metrics every 60 seconds and sends them to Insights. You can customize the interval with the `-i, --interval` flag (see the [CLI reference](/resources/cli/#agent) for details).
### Tagging metrics
[Section titled “Tagging metrics”](#tagging-metrics)
If you’re running the agent on multiple hosts, add tags to identify and group them:
```shell
hb agent --api-key PROJECT_API_KEY \
--tag environment=production \
--tag role=web-1
```
Tags appear as top-level fields on every metric event. You can also override the default hostname with `--tag host=custom-name`, which is useful when hostnames are auto-generated (e.g. IP-based names from cloud providers).
Tags can also be set in the configuration file (`~/.honeybadger-cli.yaml`):
```yaml
api_key: PROJECT_API_KEY
agent:
tags:
environment: production
role: web-1
```
CLI flags take precedence over configuration file tags. See the [CLI reference](/resources/cli/#agent) for details and examples of reserved field names that cannot be used as tag keys.
Once tagged, you can filter and group metrics in Insights:
```badgerql
fields @ts, host::str, used_percent::float
| filter event_type::str == "report.system.cpu"
| filter environment::str == "production"
| filter role::str == "web-1"
```
## Querying agent metrics in Insights
[Section titled “Querying agent metrics in Insights”](#querying-agent-metrics-in-insights)
Once metrics are flowing, you can query them in Insights. Each metric type sends a separate event:
```json
{"@id": "ca4dee56-bede-453d-a41e-a6fd93d30eaf", "@stream.id": "3XepYQVyo5to", "@ts": "2026-01-12 22:22:11.000", "total_bytes": 994662584320, "used_bytes": 544694333440, "free_bytes": 449968250880, "used_percent": 54.76, "device": "/dev/disk3s1s1", "event_type": "report.system.disk", "host": "vonnegut.lan", "mountpoint": "/", "fstype": "apfs"}
{"@id": "d76ca037-3bab-4c1c-beb1-a18b9e6ff765", "@stream.id": "3XepYQVyo5to", "@ts": "2026-01-12 22:22:11.000", "total_bytes": 51539607552, "used_bytes": 38632865792, "free_bytes": 164954112, "available_bytes": 12906741760, "used_percent": 74.96, "event_type": "report.system.memory", "host": "vonnegut.lan"}
{"@id": "5b7c4060-1ff3-4d52-90d8-a9d3af17174a", "@stream.id": "3XepYQVyo5to", "@ts": "2026-01-12 22:22:11.000", "num_cpus": 14, "used_percent": 32.85, "load_avg_1": 3.35009765625, "load_avg_5": 3.73046875, "load_avg_15": 3.86083984375, "event_type": "report.system.cpu", "host": "vonnegut.lan"}
```
Here’s an example [BadgerQL](/guides/insights/badgerql/) query to get a snapshot of disk usage:
```badgerql
fields @ts, mountpoint::str, used_percent::float
| filter event_type::str == "report.system.disk"
| sort used_percent desc
| limit 1 by mountpoint::str
```
| @ts `TIME EDT` | mountpoint `STR` | used\_percent `FLOAT` |
| ----------------------- | ---------------- | --------------------- |
| 2026-01-12 16:15:06.000 | / | 55.01 |
| 2026-01-12 16:14:21.000 | /data | 11.91 |
## Using Vector
[Section titled “Using Vector”](#using-vector)
If you need more flexibility or are already using [Vector](https://vector.dev) in your infrastructure, you can use it to send host metrics to Insights instead.
Here’s a sample configuration:
```yaml
# Put this in /etc/vector/vector.yaml
sources:
host:
type: "host_metrics"
sinks:
honeybadger_events:
type: "http"
inputs: ["host"]
uri: "https://api.honeybadger.io/v1/events"
request:
headers:
X-API-Key: "PROJECT_API_KEY"
encoding:
codec: "json"
framing:
method: "newline_delimited"
```
The easiest way to run Vector is via Docker. Here’s a sample [Docker Compose](https://docs.docker.com/compose/) configuration, assuming your Vector configuration is in a file named `vector.yaml`:
```yaml
version: "3.2"
services:
vector:
image: timberio/vector:latest-alpine
volumes:
- "vector.yaml:/etc/vector/vector.yaml:ro"
```
See the [Vector documentation](https://vector.dev/docs/reference/configuration/sources/host_metrics/) for more configuration options.
## Querying Vector’s metrics
[Section titled “Querying Vector’s metrics”](#querying-vectors-metrics)
Vector’s [metrics](https://vector.dev/docs/reference/configuration/sources/host_metrics/#output-metrics) are structured like this:
```json
{
"@id": "01922983-149f-7a69-b5e1-ddca928d815e",
"@stream.id": "cEhUcrZrnny0",
"@ts": "2025-09-25 14:08:26.048",
"gauge": {
"value": 1.25
},
"tags": {
"collector": "load",
"host": "api-10-0-11-252"
},
"kind": "absolute",
"name": "load15",
"namespace": "host"
}
```
Here’s an example [BadgerQL](/guides/insights/badgerql/) query to get a snapshot of disk usage:
```badgerql
fields @ts, tags.mountpoint::str, round(gauge.value::float * 100, 2) as used_percentage
| filter namespace::str == "host"
| filter name::str == "filesystem_used_ratio"
| filter gauge.value::float > 0.0
| filter tags.filesystem::str not in ["tmpfs", "devtmpfs", "squashfs"]
| sort @ts
| limit 1 by tags.mountpoint
```
| @ts `TIME EDT` | tags.mountpoint `STR` | used\_percentage `FLOAT` |
| ----------------------- | --------------------- | ------------------------ |
| 2025-09-25 10:45:11.047 | / | 29.77 |
| 2025-09-25 10:45:11.047 | /efs | 0 |
# Send logs and events from JavaScript apps to Honeybadger Insights
> Here's how to integrate your JavaScript apps with Honeybadger Insights.
#### Automatic instrumentation
[Section titled “Automatic instrumentation”](#automatic-instrumentation)
Capture inbound HTTP requests from Express, Fastify, AWS Lambda, and Next.js as `request.handled` events. See [Automatic instrumentation](/lib/javascript/insights/automatic-instrumentation/) for configuration and framework setup.
#### Logs
[Section titled “Logs”](#logs)
Instrument your JavaScript application, either backend or frontend, to send your logs automatically to Honeybadger Insights. More information can be found [here](/lib/javascript/insights/capturing-logs/).
#### Events
[Section titled “Events”](#events)
If you have custom events you’d like to track, use `Honeybadger.event()` to report them to Insights:
```javascript
Honeybadger.event("button_click", {
action: "buy_now",
user_id: 123,
product_id: 456,
});
```
More information about sending events to Insights from your JavaScript apps can be found [here](/lib/javascript/insights/sending-events-to-insights/).
# Use Vector to ship your log files to Honeybadger Insights
> Here's how to use Vector to watch your log files and send the events they record to Honeybadger.
You can use [Vector](https://vector.dev) to watch your existing log files and send the events they record. Here’s a sample configuration that will encode the log lines into the newline-delimited JSON format that our API expects:
```yaml
# Put this in /etc/vector/vector.yaml
sources:
app:
type: "file"
include: ["/home/app/shared/log/*.log"]
sinks:
honeybadger_events:
type: "http"
inputs: ["app"]
uri: "https://api.honeybadger.io/v1/events"
request:
headers:
X-API-Key: "PROJECT_API_KEY"
encoding:
codec: "json"
framing:
method: "newline_delimited"
```
If you are using something like [Lograge](https://github.com/roidrage/lograge) to emit JSON-formatted logs (and you should — it’s awesome), you can have Vector replace the message field with a JSON payload:
```yaml
# Put this in /etc/vector/vector.yaml
sources:
app:
type: "file"
include: ["/home/app/shared/log/*.log"]
transforms:
parse_logs:
type: "remap"
inputs: ["app"]
source: |
payload, err = parse_json(string!(.message))
if err == null {
.payload = payload
del(.message)
}
sinks:
honeybadger_events:
type: "http"
inputs: ["parse_logs"]
uri: "https://api.honeybadger.io/v1/events"
request:
headers:
X-API-Key: "PROJECT_API_KEY"
encoding:
codec: "json"
framing:
method: "newline_delimited"
```
Or if you are using logfmt-style logs, like “controller=pages action=index”, then you can add a transform that parses that into JSON:
```yaml
---
transforms:
parse_logs:
type: "remap"
inputs: ["app"]
source: |
payload, err = parse_key_value(string!(.message))
if err == null {
.payload = payload
del(.message)
}
```
Again, we **highly** recommend structured logging. 😉
By the way, Vector supports a variety of [input sources](https://vector.dev/docs/reference/configuration/sources/), such as Docker logs, Redis metrics, etc., in addition to log files. You can define whatever `sources` and `transforms` make sense for what you want to capture, then use the `sinks` section provided in the examples above to send everything to Insights.
The easiest way to run Vector is via Docker. Here’s a sample [Docker Compose](https://docs.docker.com/compose/) configuration you can use, assuming your Vector configuration is in a file named `vector.yaml`:
```yaml
version: "3.2"
services:
vector:
image: timberio/vector:latest-alpine
volumes:
- "vector.yaml:/etc/vector/vector.yaml:ro"
```
## Additional Vector configuration examples
[Section titled “Additional Vector configuration examples”](#additional-vector-configuration-examples)
### Nginx logs
[Section titled “Nginx logs”](#nginx-logs)
You can use regular expressions to extract the fields of an Nginx log to create a JSON structure in a transform:
```yaml
sources:
nginx_logs:
type: "file"
ignore_older: 86400
include:
- "/var/log/nginx/access.log"
read_from: "end"
transforms:
parse_nginx:
type: "remap"
inputs:
- "nginx_logs"
source: |
match, err = parse_regex(.message, r'(?P[^ ]*) - (?P[^ ]*) \[(?P[^\]]*)\] "(?P[^ ]*) ?(?P[^ ]*) ?(?P[^"]*)" (?P[^ ]*) (?P[^ ]*) "(?P[^"]*)" "(?P[^"]*)" (?[0-9\.]+)', true)
if err == null {
.remote_addr = match.remote_addr
.user = match.user
.timestamp = parse_timestamp(match.timestamp, "%d/%b/%Y:%H:%M:%S %z") ?? match.timestamp
.request = match.request
.method = match.method
.url = match.url
.protocol = match.protocol
.status, err = to_int(match.status)
.bytes_sent, err = to_int(match.bytes_sent)
.referer = match.referer
.user_agent = match.user_agent
.duration, err = to_float(match.duration)
del(.message)
} else {
log("Failed to parse log line: " + err, level: "error")
}
```
# Ship your Netlify logs to Honeybadger Insights
> Here's how to ship your logs from Netlify to Honeybadger Insights.
You can use Netlify’s [General HTTP endpoint](https://docs.netlify.com/monitor-sites/log-drains/?monitoring-providers=general#general-http-endpoint) to send your Netlify logs to Insights. Choose NDJSON as the Log Drain Format and enter this URL as the Full URL:
```plaintext
https://api.honeybadger.io/v1/events?api_key=PROJECT_API_KEY
```
# OpenTelemetry Protocol (OTLP)
> Send traces, metrics, and logs to Honeybadger Insights using the OpenTelemetry Protocol.
Honeybadger can ingest OpenTelemetry traces, metrics, and logs directly via the [OpenTelemetry Protocol (OTLP)](https://opentelemetry.io/docs/specs/otlp/). If you’re already using OpenTelemetry to instrument your applications, you can send that data to Honeybadger Insights without changing your instrumentation code—just point your OTLP exporter at our endpoint.
## Getting started
[Section titled “Getting started”](#getting-started)
The quickest way to send OpenTelemetry data to Honeybadger is by pointing your OTLP exporter at our endpoint:
```bash
export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.honeybadger.io
export OTEL_EXPORTER_OTLP_HEADERS=X-API-Key=PROJECT_API_KEY
```
We accept the `http/protobuf` protocol, which is the default for most SDKs. See [Authentication](#authentication) below for other ways to pass your API key.
## Authentication
[Section titled “Authentication”](#authentication)
Honeybadger accepts your project API key via either the `X-API-Key` header or a standard `Authorization: Bearer` header. Use whichever fits your exporter or collector configuration:
```bash
export OTEL_EXPORTER_OTLP_HEADERS=X-API-Key=PROJECT_API_KEY
```
```bash
export OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20PROJECT_API_KEY
```
Note that `OTEL_EXPORTER_OTLP_HEADERS` requires the space between `Bearer` and your key to be URL-encoded as `%20`.
Your API key is available on the API keys tab of your project settings page.
## Using the OpenTelemetry Collector
[Section titled “Using the OpenTelemetry Collector”](#using-the-opentelemetry-collector)
If you’re using the [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/), add an `otlphttp` exporter to your configuration:
```yaml
exporters:
otlphttp/honeybadger:
endpoint: https://api.honeybadger.io
headers:
X-API-Key: PROJECT_API_KEY
```
You can also authenticate using a bearer token:
```yaml
exporters:
otlphttp/honeybadger:
endpoint: https://api.honeybadger.io
headers:
Authorization: Bearer PROJECT_API_KEY
```
Then add `otlphttp/honeybadger` to your pipeline exporters.
## Supported signals
[Section titled “Supported signals”](#supported-signals)
We accept traces, metrics, and logs at the following endpoints:
| Signal | Endpoint |
| ------- | --------------------------------------- |
| Traces | `https://api.honeybadger.io/v1/traces` |
| Metrics | `https://api.honeybadger.io/v1/metrics` |
| Logs | `https://api.honeybadger.io/v1/logs` |
## Querying your data
[Section titled “Querying your data”](#querying-your-data)
Once your data is flowing, you can query it in [Insights](/guides/insights/) using [BadgerQL](/guides/insights/badgerql/). OpenTelemetry data appears as events with these types:
* **Traces**: `event_type` = `otel.span`
* **Metrics**: `event_type` = `otel.metric`
* **Logs**: `event_type` = `otel.log`
For example, to view recent spans:
```badgerql
fields @ts, span_name::str, duration::float, status.code::str, resource.service.name::str
| filter event_type::str == "otel.span"
| sort @ts
```
# Send logs and events from PHP apps to Honeybadger Insights
> Here's how to integrate your PHP apps with Honeybadger Insights.
#### Logs
[Section titled “Logs”](#logs)
Instrument your PHP application, either a Lumen, a Laravel or a plain PHP app, to send your logs automatically to Honeybadger Insights. More information can be found [here](/lib/php/insights/capturing-logs/).
#### Events
[Section titled “Events”](#events)
If you are using Laravel or Lumen, enable the automatic events instrumentation :
```php
'events' => [
'enabled' => true,
'automatic' => HoneybadgerLaravel::DEFAULT_EVENTS,
],
```
If you have custom events you’d like to track, use `Honeybadger.event()` to report them to Insights:
```php
Honeybadger.event('button_click', [
'action' => 'buy_now',
'user_id' => 123,
'product_id' => 456
])
```
More information about sending events to Insights from your PHP apps can be found [here](/lib/php/insights/sending-events-to-insights/).
# Send logs and events from Python apps to Honeybadger Insights
> Here's how to integrate your Python apps with Honeybadger Insights.
When enabled, Honeybadger [automatically instruments your Python application](/lib/python/insights/automatic-instrumentation/) to send application events to Honeybadger Insights. This is the easiest way to get started with Insights. To get started, enable Insights in your app configuration:
```python
from honeybadger import honeybadger
honeybadger.configure(insights_enabled=True)
```
Once integrated with our middleware or extensions, Honeybadger instruments the following libraries:
* **Django** requests & database queries
* **Flask** requests & database queries
* **ASGI** requests (FastAPI, Starlette, etc.)
* **Celery** tasks
* **Oban** workers & maintenance loops
See the [automatic instrumentation guide](/lib/python/insights/automatic-instrumentation/) to learn how to configure each integration, and the [Python event reference](/insights/event-types/python/) for every event the package emits, with field schemas and types. You can also [add extra context data](/lib/python/insights/event-context/) to events, [filter events](/lib/python/insights/filtering-events/) to remove PII, and [sample events](/lib/python/insights/sampling-events/) to reduce the amount of data sent to Honeybadger.
## Querying events with BadgerQL
[Section titled “Querying events with BadgerQL”](#querying-events-with-badgerql)
Once events are flowing into Insights, you can query them with [BadgerQL](/guides/insights/badgerql/). For example, to find your slowest Django views:
```plaintext
filter event_type::str == "django.request"
| stats avg(duration::float) as avg_duration, count() as requests by view::str
| sort avg_duration desc
```
Or to see Oban background-job throughput and p95 duration by worker:
```plaintext
filter event_type::str == "oban.job_finished"
| stats count() as jobs, percentile(95, duration::float) as p95_ms by worker::str
| sort jobs desc
```
The [Python event reference](/insights/event-types/python/) lists the fields available on each event type.
## Sending custom events
[Section titled “Sending custom events”](#sending-custom-events)
If you have custom events you’d like to track, use `honeybadger.event` to report them to Insights:
```python
from honeybadger import honeybadger
honeybadger.event("user.signup", {"user_id": user.id, "plan": user.plan})
```
More information about sending events to Insights from your Python apps can be found [here](/lib/python/insights/sending-custom-events/).
## Sending logs from your infrastructure
[Section titled “Sending logs from your infrastructure”](#sending-logs-from-your-infrastructure)
Honeybadger isn’t just for errors and application data! You can use our [syslog](/guides/insights/integrations/systemd/), [Vector](/guides/insights/integrations/log-files/), or [PaaS integrations](/guides/insights/#adding-data-from-other-sources) to send additional data from your infrastructure to [Honeybadger Insights](/guides/insights/), where you can query, visualize, and analyze all of your production data in one place.
# Ship your rsyslog logs to Honeybadger Insights
> Use rsyslog to forward system and application logs to Honeybadger Insights over syslog-TLS.
[rsyslog](https://www.rsyslog.com/) is the default syslog daemon on most Linux distributions. You can configure it to forward logs to Honeybadger Insights over syslog-TLS (RFC 5425), tagging each message with your project’s API key in the structured-data section of the RFC 5424 payload.
## Requirements
[Section titled “Requirements”](#requirements)
Install the TLS driver package for rsyslog. On Debian and Ubuntu:
```shell
sudo apt-get install rsyslog-gnutls
```
On RHEL, Fedora, and derivatives:
```shell
sudo dnf install rsyslog-gnutls
```
You’ll also need the CA certificate bundle for your system. On Debian/Ubuntu this is `/etc/ssl/certs/ca-certificates.crt`. On RHEL/Fedora it’s `/etc/pki/tls/certs/ca-bundle.crt`.
## Configuration
[Section titled “Configuration”](#configuration)
/etc/rsyslog.d/60-honeybadger.conf
```plaintext
# Load the TLS network stream driver. Set the CA file to match your OS:
# Debian/Ubuntu: /etc/ssl/certs/ca-certificates.crt
# RHEL/Fedora: /etc/pki/tls/certs/ca-bundle.crt
global(DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="/etc/ssl/certs/ca-certificates.crt")
# RFC 5424 template with Honeybadger structured data
template(name="HoneybadgerFormat" type="string"
string="<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% [honeybadger@61642 api_key=\"PROJECT_API_KEY\" event_type=\"rsyslog\"] %msg%\n")
# Forward all logs to Honeybadger over syslog-TLS (RFC 5425)
action(type="omfwd"
Target="in.honeybadger.io"
Port="6514"
Protocol="tcp"
TCP_Framing="octet-counted"
StreamDriver="gtls"
StreamDriverMode="1"
StreamDriverAuthMode="x509/name"
StreamDriverPermittedPeers="*.honeybadger.io"
template="HoneybadgerFormat")
```
Restart rsyslog to pick up the change:
```shell
sudo systemctl restart rsyslog
```
You can add additional key/value pairs to the structured-data section of the template. For example, to tag every event with an environment, replace the `string=` value inside the `template(name="HoneybadgerFormat" ...)` block above with the following:
```plaintext
string="<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% [honeybadger@61642 api_key=\"PROJECT_API_KEY\" event_type=\"rsyslog\" environment=\"production\"] %msg%\n"
```
## Shipping application log files with imfile
[Section titled “Shipping application log files with imfile”](#shipping-application-log-files-with-imfile)
rsyslog’s [`imfile`](https://www.rsyslog.com/doc/configuration/modules/imfile.html) module can tail arbitrary log files and feed them through the same pipeline, which is handy if your application writes to its own log file instead of stdout. Add the following to the top of `/etc/rsyslog.d/60-honeybadger.conf` (before the `action(...)` block):
```plaintext
# Load the file input module
module(load="imfile" PollingInterval="10")
# Tail your application's log files
input(type="imfile"
File="/var/log/myapp/*.log"
Tag="myapp"
Severity="info"
Facility="local7")
```
Each line written to a matching file will be forwarded to Honeybadger using the `HoneybadgerFormat` template, with `APP-NAME` set to the `Tag` value (`myapp`). Adjust `File`, `Tag`, `Severity`, and `Facility` to match your application.
If you’d rather only forward the events captured by `imfile` (and not every other message rsyslog processes), wrap the action in a conditional:
```plaintext
if ($programname == "myapp") then {
action(type="omfwd"
Target="in.honeybadger.io"
Port="6514"
Protocol="tcp"
TCP_Framing="octet-counted"
StreamDriver="gtls"
StreamDriverMode="1"
StreamDriverAuthMode="x509/name"
StreamDriverPermittedPeers="*.honeybadger.io"
template="HoneybadgerFormat")
}
```
## Querying your data
[Section titled “Querying your data”](#querying-your-data)
Once your data is flowing, you can query it in [Insights](/guides/insights/) using [BadgerQL](/guides/insights/badgerql/). The following query will return events sent via rsyslog:
```badgerql
fields @ts, hostname::str, appname::str, severity::str, message::str
| filter event_type::str == "rsyslog"
| sort @ts
```
## Troubleshooting
[Section titled “Troubleshooting”](#troubleshooting)
If events aren’t showing up in Insights, check rsyslog’s own log for TLS or forwarding errors:
```shell
sudo journalctl -u rsyslog -f
```
A missing or incorrect CA file is the most common cause of connection failures — double-check the `DefaultNetstreamDriverCAFile` path against what’s installed on your system.
# Send metrics and events from Ruby and Rails apps to Honeybadger Insights
> Here's how to integrate your Ruby/Ruby on Rails apps with Honeybadger Insights.
#### Logs
[Section titled “Logs”](#logs)
Sending your logs to Insights is a quick way to get some visibility into your app. There are two good options:
##### Semantic Logger
[Section titled “Semantic Logger”](#semantic-logger)
Use the [rails\_semantic\_logger gem](https://github.com/reidmorrison/rails_semantic_logger) and enable the `HoneybadgerInsights` appender by adding `config.semantic_logger.add_appender(appender: :honeybadger_insights)` to `config/application.rb`. Outside of Rails, you can use the same appender with the [semantic\_logger gem](https://github.com/reidmorrison/semantic_logger).
Please note that if you are using SolidQueue, you will need to add the following snippet to `config/initializers/solid_queue.rb` to work around a [known issue with Semantic Logger](https://github.com/reidmorrison/rails_semantic_logger/issues/237) that causes SolidQueue/ActiveJob logging to not be sent to Insights:
```yaml
# Re-open appenders after forking the worker, dispatcher, and scheduler processes
SolidQueue.on_worker_start { SemanticLogger.reopen }
SolidQueue.on_dispatcher_start { SemanticLogger.reopen }
SolidQueue.on_scheduler_start { SemanticLogger.reopen }
```
##### Lograge
[Section titled “Lograge”](#lograge)
Use [Lograge](https://github.com/roidrage/lograge) to emit JSON-formatted output to your log files and Vector to [forward them to Insights](/guides/insights/integrations/log-files/). If you go this route, be sure to disable the log tagging in your Rails environment config (`config/environments/production.rb`) by commenting out the `config.log_tags` line, as that will mess with the JSON output.
#### Metrics
[Section titled “Metrics”](#metrics)
You can get more details about what’s happening in your application by enabling our gem’s automatic instrumentation, which will report information about every SQL query, HTTP request, etc. to Insights. This will consume more Insights quota than the logging approach, but you will get much more data to use for analyzing your app’s performance, and this will populate our ready-made Rails dashboard, which includes charts for request duration, SQL query counts, and more. More information can be found [here](/lib/ruby/insights/collecting-and-reporting-metrics).
Alternatively, you can use [Yabeda](https://github.com/yabeda-rb/yabeda) and [our Yabeda integration](https://github.com/honeybadger-io/yabeda-honeybadger_insights) to collect and report metrics in your Ruby and Rails apps. Several default metrics, such as request counts, request duration, etc., will be reported automatically once you’ve added and configured the gems. Alternatively, you can use [Yabeda](https://github.com/yabeda-rb/yabeda) and [our Yabeda integration](https://github.com/honeybadger-io/yabeda-honeybadger_insights) to collect and report metrics in your Ruby and Rails apps. Several default metrics, such as request counts, request duration, etc., will be reported automatically once you’ve added and configured the gems.
#### Events
[Section titled “Events”](#events)
If you have custom events you’d like to track, use `Honeybadger#event` to report those events to Insights:
app/controllers/accounts\_controller.rb
```ruby
class AccountsController < ApplicationController
def create
# Account.create(...)
Honeybadger.event("Created account", account_id: account.id, account_name: account.name, plan: account.subscription.name)
end
end
```
More information about sending events to Insights from your Ruby and Rails apps can be found [here](/lib/ruby/insights/sending-events-to-insights).
# Send CI/CD telemetry from RWX to Honeybadger Insights
> Here's how to send CI/CD telemetry from RWX (Mint) to Honeybadger Insights using OpenTelemetry.
[RWX](https://www.rwx.com/) can send CI/CD pipeline telemetry to Honeybadger Insights using [OpenTelemetry](/guides/insights/integrations/opentelemetry/), giving you visibility into pipeline runs, task durations, and failures.
Tip
RWX’s observability integration is organization-wide rather than per-repository. If you want to keep CI telemetry separate from your application data, consider creating a dedicated Honeybadger project for it.
## Configuration
[Section titled “Configuration”](#configuration)
1. Go to your [RWX organization observability settings](https://cloud.rwx.com/org/deep_link/manage/mint/observability).
2. Select **Honeybadger** as the OpenTelemetry provider.
3. The endpoint will default to `https://api.honeybadger.io/v1/traces`.
4. Enter your Honeybadger API key, which is available on the API keys tab of your [project settings](/guides/projects/).
## Querying your data
[Section titled “Querying your data”](#querying-your-data)
Once you’re receiving telemetry, you can query your CI/CD data in [Insights](/guides/insights/) using [BadgerQL](/guides/insights/badgerql/). RWX sends OpenTelemetry spans with [CI/CD semantic convention](https://opentelemetry.io/docs/specs/semconv/cicd/cicd-metrics/) fields.
View recent pipeline tasks:
```badgerql
fields @ts, span_name::str, cicd.pipeline.task.run.result::str, duration::int
| filter event_type::str == "otel.span"
| filter resource.service.name::str == "rwx"
| sort @ts desc
```
Find failed tasks:
```badgerql
fields @ts, span_name::str, cicd.pipeline.run.git.repository::str, cicd.pipeline.run.git.branch::str
| filter event_type::str == "otel.span"
| filter resource.service.name::str == "rwx"
| filter cicd.pipeline.task.run.result::str == "failure"
| sort @ts desc
```
Analyze task durations:
```badgerql
fields cicd.pipeline.task.name::str, cicd.pipeline.task.run.timing.runtime.ms::int
| filter event_type::str == "otel.span"
| filter resource.service.name::str == "rwx"
| filter cicd.pipeline.task.name::str != "$run"
| stats avg(cicd.pipeline.task.run.timing.runtime.ms::int), max(cicd.pipeline.task.run.timing.runtime.ms::int) by cicd.pipeline.task.name::str
```
## Learn more
[Section titled “Learn more”](#learn-more)
* [RWX Honeybadger integration docs](https://www.rwx.com/docs/observability/honeybadger)
* [OpenTelemetry CI/CD semantic conventions](https://opentelemetry.io/docs/specs/semconv/cicd/cicd-metrics/)
* [Honeybadger OpenTelemetry integration](/guides/insights/integrations/opentelemetry/)
# Use Vector to ship your systemd logs to Honeybadger Insights
> Here's how to use Vector to watch journald and send events to Honeybadger.
[Journald](https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html) is the logging system used by [systemd](https://systemd.io), the init system used on most modern Linux distributions. It’s a replacement for syslog and rsyslog, and it captures the logs for just about everything running on a Linux server, including services like web and database servers that are managed by systemd. Any systemd-managed process that sends output to stdout will show that output in journald.
You can use [Vector](https://vector.dev) to watch journald and relay the events it captures. Here’s a sample configuration that will encode the journald’s data into the newline-delimited JSON format that our API expects:
```yaml
# Put this in /etc/vector/vector.yaml
sources:
journald:
type: journald
include_matches:
_TRANSPORT:
- stdout
# See the Vector Remap Language reference for more info: https://vrl.dev
transforms:
parse_logs:
type: "remap"
inputs: ["journald"]
source: |
. = {"host": .host, "unit": ._SYSTEMD_USER_UNIT || ._SYSTEMD_UNIT, "message": .message, "timestamp": .timestamp}
structured = parse_json(.message) ?? {}
. = merge!(., structured)
sinks:
honeybadger:
type: "http"
inputs: ["parse_logs"]
uri: "https://api.honeybadger.io/v1/events"
request:
headers:
X-API-Key: "PROJECT_API_KEY"
encoding:
codec: "json"
framing:
method: "newline_delimited"
batch:
max_bytes: 1000000
```
Since journald captures *everything* that happens on your server, and since you probably don’t care about stuff like kernel messages, the `sources` section of the configuration limits what it will pass on to Honeybadger. This configuration will only relay events that were emitted to stdout, like web server logs, Rails application logs, and that sort of thing. If you really want to send everything that gets logged to journald, you can delete the `include_matches` portion of the configuration. See the [Vector documentation](https://vector.dev/docs/reference/configuration/sources/journald/) for more info on filtering the journald input.
The `parse_logs` transformation also reduces the amount of data sent to Insights by stripping out things like the process ID, the user running the service, etc. If you decide you want to be able to query that data in Insights, you can remove the transform and change the `honeybadger` sink `inputs` from “parse\_logs” to “journald”.
Please see our documentation on ingesting [log files](/guides/insights/integrations/log-files/) for a few more handy transformations you can use in your Vector configuration.
## Quick setup method
[Section titled “Quick setup method”](#quick-setup-method)
If you’re running a system that uses apt to manage packages, like Debian or Ubuntu, you can use the following command to fetch and run a [script](https://gist.github.com/stympy/9ccb5a809a6731f53b3335fb4e020c2c#file-install_vector-sh) that installs the Vector package, sets up the configuration file, and starts Vector as a service:
```shell
curl -sL https://gist.github.com/stympy/9ccb5a809a6731f53b3335fb4e020c2c/raw/bc5741a4e277ea3a7d6d0f5e70a67e0767aec221/install_vector.sh > install_vector.sh && \
chmod a+x install_vector.sh && \
HONEYBADGER_API_KEY="PROJECT_API_KEY" ./install_vector.sh
```
# Integrations
> Send Honeybadger data to other services.
Honeybadger has deep support for a wide variety of [third-party integrations](#supported-integrations). This page provides an overview of some cool features available for every integration. These settings are located at **Project settings > Alerts & integrations**. You can click the edit icon and customize the notifications for each integration.
## Customizing integration notifications
[Section titled “Customizing integration notifications”](#customizing-integration-notifications)
### Errors
[Section titled “Errors”](#errors)
You get to choose which error events result in a notification or ticket being created:
### Uptime checks
[Section titled “Uptime checks”](#uptime-checks)
You can edit which uptime events are sent to the integration for all or a subset of the project’s uptime checks:
### Check-Ins
[Section titled “Check-Ins”](#check-ins)
And you can also change what check-in events are reported:
### Environments
[Section titled “Environments”](#environments)
You can ignore environments. We auto-populate the list based on environments we’ve seen in your app.
## Rate escalations
[Section titled “Rate escalations”](#rate-escalations)
Escalations let you receive extra notifications when your error rate exceeds a number you’ve configured.
## Error volume anomaly detection
[Section titled “Error volume anomaly detection”](#error-volume-anomaly-detection)
Anomaly detection alerts you when a project’s **total error volume** deviates from its learned baseline. Unlike [rate escalations](#rate-escalations), which fire at a fixed threshold you have set, anomaly detection learns each project’s normal hourly error volume and notifies you when the current rate is statistically unusual (for example, “errors are 4.7× your normal rate”).
Turn it on per integration in the **Anomaly detection** section in the integration’s options. Honeybadger evaluates your projects every few minutes and sends a single notification when a spike begins. A two-hour cooldown then suppresses repeat alerts so a sustained spike notifies you once rather than continuously.
Anomaly detection needs enough history to learn what’s normal — at least 48 hours of error activity. Brand-new or very quiet projects won’t trigger alerts until they’ve accumulated enough data.
Spike alerts go to notification and alerting integrations (email, Slack, SMS, PagerDuty, Opsgenie, Microsoft Teams, webhooks, and similar). Issue-tracker integrations (GitHub, Jira, Linear, and the like) don’t receive spike alerts, since a spike is an alert rather than a fileable issue.
See the structure of the JSON sent to webhook and event-based integrations in the [`volume_spike` payload](/guides/integrations/payloads/volume_spike/).
## Throttling
[Section titled “Throttling”](#throttling)
Avoid floods of notifications when everything goes wrong at once.
## Filters
[Section titled “Filters”](#filters)
With filters, you can be hyper-precise about which errors trigger notifications or issue creation. You could:
* Create issues in separate trackers for staging, prepared and production
* Route notifications to a certain team’s inbox whenever an error assigned to that team reoccurs.
The syntax for error filters is essentially the same as our search syntax, with a few limitations:
* You can’t filter on params, context, session or other per-notice data
* Filters don’t support freeform text search. You must use the `key:val` syntax.
Below is a list of fields you can use when constructing your queries. Note that you can prefix any query with `-` to create its inverse.
| Example query | Matches |
| ------------------------------- | ------------------------------------------ |
| `is:resolved` | Resolved errors |
| `is:paused` | Paused errors |
| `is:ignored` | Ignored errors |
| `assignee:"nobody"` | Unassigned errors |
| `assignee:"anybody"` | Errors assigned to anyone |
| `assignee:"jane@email.com"` | Errors assigned to a specific person |
| `environment:"production"` | Errors occurring in production |
| `class:"PermissionDeniedError"` | Errors with a certain class |
| `tag:"tag_example"` | Errors with a tag |
| `message:"404"` | Errors with a message |
| `component:"UsersController"` | Errors occurring in a controller/component |
| `action:"update"` | Errors occurring in an action |
Multiple filters are evaluated using a logical OR. If any query matches the error, a notification will be sent. When using negative queries like `-class:Foo`, this OR behavior can give unexpected results. To combine multiple negative matches, use a single filter with a search term like `-class:"Foo" AND -class:"Bar"`.
## Custom formatters
[Section titled “Custom formatters”](#custom-formatters)
For some of our integrations, we allow the option to provide a custom format for specific fields (e.g., email subject line or Trello card title). Your custom format will be used for all events that are applicable for the integration (reported, assigned, marked as resolved, etc).
The following is a list of valid formatter tokens:
| Token | Description |
| --------------- | ----------------------------------------------------------------------------------- |
| `[project]` | The project name |
| `[environment]` | The operating environment — production, development, etc. |
| `[type]` | The event type — occurred, assigned, etc. |
| `[class]` | The class of the error associated with the event |
| `[message]` | The message of the error associated with the event |
| `[component]` | The component name (might be null, usually maps to the controller name) |
| `[action]` | The action name (might be null, usually maps to the controller action e.g. `index`) |
| `[fault_id]` | A unique id for the fault event |
| `[file]` | The filename with path and line number where the error occurred |
| `[backtrace]` | The backtrace of the error associated with the event (first 3 lines) |
| `[url]` | The URL of the event in the Honeybadger UI |
## Supported integrations
[Section titled “Supported integrations”](#supported-integrations)
Your Honeybadger data can be sent to a variety of third-party services, listed below. We support creating issues for errors in the SCM and project management tools, such as GitHub and Jira. For communication tools like Slack and PagerDuty, we can send notifications for errors, sites that go down (and come back up), and check-ins.
[AlertOps](/guides/integrations/alertops/)Send alerts to AlertOps
[Asana](/guides/integrations/asana/)Create Asana tasks from errors
[Backlog](/guides/integrations/backlog/)Create Backlog issues from errors
[Bitbucket](/guides/integrations/bitbucket/)Create Bitbucket issues from errors
[Campfire](/guides/integrations/campfire/)Send notifications to Campfire
[ClickUp](/guides/integrations/clickup/)Create ClickUp tasks from errors
[ClickUp Chat](/guides/integrations/clickup-chat/)Send messages to ClickUp Chat
[Datadog](/guides/integrations/datadog/)Send events to Datadog
[Discord](/guides/integrations/discord/)Send notifications to Discord
[Email](/guides/integrations/email/)Receive email notifications
[GitHub](/guides/integrations/github/)Create GitHub issues from errors
[GitLab](/guides/integrations/gitlab/)Create GitLab issues from errors
[Google Chat](/guides/integrations/google-chat/)Send messages to Google Chat
[ilert](/guides/integrations/ilert/)Create ilert alerts
[incident.io](/guides/integrations/incident-io/)Create incidents in incident.io
[Instatus](/guides/integrations/instatus/)Update Instatus status page
[Intercom](/guides/integrations/intercom/)Send messages to Intercom
[Jira & Jira Cloud](/guides/integrations/jira/)Create Jira issues from errors
[Linear](/guides/integrations/linear/)Create Linear issues from errors
[Mattermost](/guides/integrations/mattermost/)Send notifications to Mattermost
[Microsoft Teams](/guides/integrations/microsoft-teams/)Send messages to Microsoft Teams
[OpsGenie](/guides/integrations/opsgenie/)Create OpsGenie alerts
[PagerDuty](/guides/integrations/pagerduty/)Create PagerDuty incidents
[PagerTree](/guides/integrations/pagertree/)Create PagerTree alerts
[Redmine](/guides/integrations/redmine/)Create Redmine issues from errors
[Rootly](/guides/integrations/rootly/)Create Rootly incidents
[Shortcut](/guides/integrations/shortcut/)Create Shortcut stories from errors
[Slack](/guides/integrations/slack/)Send notifications to Slack
[Splunk On-Call](/guides/integrations/splunk-on-call/)Create Splunk On-Call incidents
[Sprintly](/guides/integrations/sprintly/)Create Sprintly items from errors
[Trello](/guides/integrations/trello/)Create Trello cards from errors
[Webhook](/guides/integrations/webhook/)Send webhooks to custom endpoints
[Zulip](/guides/integrations/zulip/)Send messages to Zulip
# AlertOps
> Connect Honeybadger to AlertOps to route notifications through your incident management and alerting system.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the AlertOps integration
[Section titled “1. Select the AlertOps integration”](#1-select-the-alertops-integration)
 
### 2. Enter the AlertOps URL
[Section titled “2. Enter the AlertOps URL”](#2-enter-the-alertops-url)
After you set up the [integration URL](https://honeybadger.alertops.com/admin/MappingRulesList.aspx) at AlertOps, you can enter that URL here.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You’re good to go.
# Asana
> Connect Honeybadger to Asana to automatically create tasks from errors and track bug fixes in your project workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Asana integration
[Section titled “1. Select the Asana integration”](#1-select-the-asana-integration)
### 2. Enter your project ID
[Section titled “2. Enter your project ID”](#2-enter-your-project-id)
You can find your Project ID from a project view. See the input hint for more details on where the ID is located.
### 3. Connect via OAuth
[Section titled “3. Connect via OAuth”](#3-connect-via-oauth)
Select the “Connect OAuth” button and give access to our app.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Backlog
> Connect Honeybadger to Backlog to automatically create issues from errors and track bug fixes in your project workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
[Backlog](https://backlog.com/) is a project management and collaboration platform that helps teams track issues, tasks, and bugs. Honeybadger automatically creates issues in Backlog when errors occur and keeps the status in sync, making it easy to track bug fixes as part of your project workflow.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Backlog integration
[Section titled “1. Select the Backlog integration”](#1-select-the-backlog-integration)
### 2. Enter your Space URL
[Section titled “2. Enter your Space URL”](#2-enter-your-space-url)
Your Space URL is the full URL of your Backlog space, including the protocol. For example:
* `https://example.backlog.com` (for international spaces)
* `https://example.backlog.jp` (for Japanese spaces)
### 3. Set the API key
[Section titled “3. Set the API key”](#3-set-the-api-key)
You can generate an API key from your Backlog account:
1. Go to **Personal Settings** in Backlog
2. Navigate to the **API** section
3. Generate a new API key
4. Copy the key and paste it into the API Key field
### 4. Fetch projects
[Section titled “4. Fetch projects”](#4-fetch-projects)
Click the **Fetch Projects** button to retrieve your Backlog projects. This will populate the project dropdown and enable the remaining configuration options.
### 5. Select project and configure issue settings
[Section titled “5. Select project and configure issue settings”](#5-select-project-and-configure-issue-settings)
Choose the Backlog project where issues should be created, then configure the required settings:
* **Issue Type**: The type of issue to create (bug, task, etc.)
* **Priority**: The priority level for created issues
* **Closed Status**: The status to transition issues to when errors are marked as resolved
* **Open Status**: The status to transition issues to when errors are reopened
By default, Honeybadger will automatically create a Backlog issue when a new error occurs, and sync status updates between Backlog and Honeybadger. See [Two-way sync with Backlog](#two-way-sync-with-backlog) for additional options.
### 6. Save
[Section titled “6. Save”](#6-save)
That’s it! You can test the integration by clicking “Test this integration”. Otherwise, just save it and you’re ready to go.
## Two-way sync with Backlog
[Section titled “Two-way sync with Backlog”](#two-way-sync-with-backlog)
Honeybadger provides seamless two-way synchronization with Backlog by default.
**From Honeybadger to Backlog:**
* **Automatically create an issue when an error occurs:** When a new error occurs, Honeybadger creates a new issue in Backlog with the **Open Status**
* **Automatically resolve issues**: When you resolve an error in Honeybadger, Honeybadger transitions the Backlog issue to the **Closed Status**
* **Automatically reopen issues**: When you unresolve (reopen) an error in Honeybadger, Honeybadger transitions the Backlog issue to the **Open Status**
**From Backlog to Honeybadger:**
* **Sync status from Backlog**: Honeybadger creates [a webhook](https://support.nulab.com/hc/en-us/articles/8840133998489-How-to-add-and-manage-webhooks-in-Backlog) in your Backlog project that automatically syncs status changes back to Honeybadger:
* When a Backlog issue’s status changes to your selected **Closed Status**: the error is automatically resolved in Honeybadger
* When a Backlog issue’s status changes from your selected **Closed Status** to any other status: the error is automatically unresolved in Honeybadger
These options are enabled by default to keep your Backlog issues and Honeybadger errors in sync automatically. You can uncheck any of these options if you prefer to create/update issues manually.
For additional integration options, see the [integrations guide](/guides/integrations/).
# Bitbucket
> Connect Honeybadger to Bitbucket to automatically create issues from errors and link commits to deployments.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Bitbucket integration
[Section titled “1. Select the Bitbucket integration”](#1-select-the-bitbucket-integration)
 
### 2. Set the repository name
[Section titled “2. Set the repository name”](#2-set-the-repository-name)
The repository name includes the account name. For example, Honeybadger has a repo called “docs” the repository name we’d enter here is “honeybadger/docs”.
### 3. Authenticate
[Section titled “3. Authenticate”](#3-authenticate)
Click “Save and Authenticate With Bitbucket” to complete setup. This will send you to bitbucket.org to authenticate via OAuth.
# Campfire
> Connect Honeybadger to Campfire to receive real-time application monitoring alerts directly in your team's chat rooms.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Campfire integration
[Section titled “1. Select the Campfire integration”](#1-select-the-campfire-integration)
 
### 2. Create a chatbot integration in Basecamp
[Section titled “2. Create a chatbot integration in Basecamp”](#2-create-a-chatbot-integration-in-basecamp)
You can configure chatbots under **Basecamp** → **\[Your project]** → **Chat** → **…** (click the three dots in the upper right-hand corner of the chat window to get the context menu).
To add a chatbot, click **Configure chatbots** → **Add a new chatbot**, and type “Honeybadger” in the `Name` field.
You can optionally upload an avatar (i.e. [our logo](https://www.honeybadger.io/assets/)). Leave `Command URL` blank.
### 3. Set the chatbot URL in Honeybadger
[Section titled “3. Set the chatbot URL in Honeybadger”](#3-set-the-chatbot-url-in-honeybadger)
After you create the chatbot in Basecamp, click on “Send line from this integration to Chat…” and copy/paste the URL in the example into the
`Chatbot URL` field in Honeybadger.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# ClickUp
> Connect Honeybadger to ClickUp to automatically create tasks from errors and track bug fixes in your workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the ClickUp integration
[Section titled “1. Select the ClickUp integration”](#1-select-the-clickup-integration)
### 2. Connect via OAuth
[Section titled “2. Connect via OAuth”](#2-connect-via-oauth)
An OAuth dialog should appear. Log in to your account and grant access to one or more workspaces. You’ll then be redirected back to the integration page.
### 3. Select workspace and teamspace
[Section titled “3. Select workspace and teamspace”](#3-select-workspace-and-teamspace)
Select one of the available workspaces and then a teamspace.
### 4. Select a list (or folder first)
[Section titled “4. Select a list (or folder first)”](#4-select-a-list-or-folder-first)
If the task list you are looking for is in a folder, select that folder first. Task lists that are not in a folder will be immediately listed in the dropdown.
### 5. Set statuses
[Section titled “5. Set statuses”](#5-set-statuses)
After selecting a task list, set the “initial”, “resolve”, and “reopen” statuses.
### 6. Tags
[Section titled “6. Tags”](#6-tags)
Add a list of comma-separated tags you wish to be associated when a task is created.
### 7. Save
[Section titled “7. Save”](#7-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# ClickUp Chat
> Connect Honeybadger to ClickUp Chat to receive real-time application monitoring alerts in your team's chat workspace.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the ClickUp Chat integration
[Section titled “1. Select the ClickUp Chat integration”](#1-select-the-clickup-chat-integration)
### 2. Connect via OAuth
[Section titled “2. Connect via OAuth”](#2-connect-via-oauth)
An OAuth dialog should appear. Log in to your account and grant access to one or more workspaces. You’ll then be redirected back to the integration page.
### 3. Select workspace and channel
[Section titled “3. Select workspace and channel”](#3-select-workspace-and-channel)
Select one of the available workspaces and then a channel where the bot will post.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Datadog
> Connect Honeybadger to Datadog to send application events to your monitoring systems and create unified observability.
Datadog is an enterprise platform for infrastructure and application monitoring. Connect Honeybadger to Datadog to surface errors, uptime events, and Insights alarms directly in your Datadog event stream—bringing developer-focused monitoring into your existing observability workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Install the integration in Datadog
[Section titled “1. Install the integration in Datadog”](#1-install-the-integration-in-datadog)
Click the **Install Integration** button on the [Honeybadger Integration Tile](https://app.datadoghq.com/account/settings#integrations/honeybadger) in Datadog.
### 2. Select the Datadog integration in Honeybadger
[Section titled “2. Select the Datadog integration in Honeybadger”](#2-select-the-datadog-integration-in-honeybadger)
 
### 3. Set the API key
[Section titled “3. Set the API key”](#3-set-the-api-key)
You can generate a Datadog API key from your [Datadog organization settings page](https://app.datadoghq.com/organization-settings/api-keys).
### 4. Select region
[Section titled “4. Select region”](#4-select-region)
Choose from the following supported Datadog regions: US1, US3, US5, US1-FED, EU1, or AP1.
### 5. Select label (optional)
[Section titled “5. Select label (optional)”](#5-select-label-optional)
If you have multiple Datadog integrations, you can add a label to differentiate in the integration list view.
### 6. Choose whether to send metrics
[Section titled “6. Choose whether to send metrics”](#6-choose-whether-to-send-metrics)
Enabling the “Send metrics” option will result in the metric `honeybadger.occurrences_per_minute` to be reported to Datadog.
### 7. Save
[Section titled “7. Save”](#7-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Discord
> Connect Honeybadger to Discord to receive real-time application monitoring alerts directly in your team's channels.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select Discord from the integrations list
[Section titled “1. Select Discord from the integrations list”](#1-select-discord-from-the-integrations-list)
### 2. Enter your Discord webhook URL
[Section titled “2. Enter your Discord webhook URL”](#2-enter-your-discord-webhook-url)
You can find your Discord Webhook URL under Channel Settings > Webhooks.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Email
> Configure email notifications from Honeybadger to receive real-time application monitoring alerts and incident updates directly in your inbox.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
Heads Up! This isn’t where you configure your personal email notifications. This email channel is specifically for integrating with services like Basecamp which consume inbound email.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Email integration
[Section titled “1. Select the Email integration”](#1-select-the-email-integration)
 
### 2. Enter the email address
[Section titled “2. Enter the email address”](#2-enter-the-email-address)
It’s just an email address, folks. I’m sure you can figure it out. :wink:
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! Just save and you’re ready to go.
# GitHub
> Connect Honeybadger to GitHub to automatically create issues from errors and link commits to deployments.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the GitHub integration
[Section titled “1. Select the GitHub integration”](#1-select-the-github-integration)
 
### 2. Authenticate
[Section titled “2. Authenticate”](#2-authenticate)
If you haven’t already granted our GitHub app access to your account, you will be prompted to do so. After that is done, you’ll be prompted to install our GitHub app in your GitHub repositories. Once that’s done, you’ll be able to create a new GitHub integration.
### 3. Set the repository name
[Section titled “3. Set the repository name”](#3-set-the-repository-name)
The repository name includes the account or organization name. For example, our gem is hosted at , so we’d enter “honeybadger-io/ruby” for the repo name to connect to that repository.
### 4. Enter labels (optional)
[Section titled “4. Enter labels (optional)”](#4-enter-labels-optional)
If you’d like us to label issues we create in GitHub, just enter a comma-separated list of tags here.
### 5. Title format (optional)
[Section titled “5. Title format (optional)”](#5-title-format-optional)
Customize the issue title, if you want, with our handy [custom formatters](/guides/integrations/#custom-formatters).
### 6. Send a detailed issue body (optional)
[Section titled “6. Send a detailed issue body (optional)”](#6-send-a-detailed-issue-body-optional)
By default, Honeybadger creates GitHub issues with a short backtrace excerpt and a link back to the fault in Honeybadger. Enable **Send a detailed issue body** to instead create issues with a full Markdown body that includes context, parameters, and the backtrace. Note that enabling this sends more potentially sensitive fault data to GitHub.
### 7. Save
[Section titled “7. Save”](#7-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# GitLab
> Connect Honeybadger to GitLab to automatically create issues from errors and link commits to deployments.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the GitLab integration
[Section titled “1. Select the GitLab integration”](#1-select-the-gitlab-integration)
 
### 2. Set the repository name
[Section titled “2. Set the repository name”](#2-set-the-repository-name)
The repository name includes the account or organization name. For example, if your project is hosted at , you’d enter “honeybadger-io/app” for the repo name to connect to that repository.
### 3. Enter labels (optional)
[Section titled “3. Enter labels (optional)”](#3-enter-labels-optional)
If you’d like us to label issues we create in GitLab, just enter a comma-separated list of tags here.
### 4. Enter server URL and personal access token (optional)
[Section titled “4. Enter server URL and personal access token (optional)”](#4-enter-server-url-and-personal-access-token-optional)
Our default configuration assumes you are hosting your code at gitlab.com and that we’ll use OAuth to connect to your account for creating issues. If you are using a self-hosted version of GitLab, then enter the URL of the GitLab installation and enter a personal access token. We will use that personal access token (generated in the GitLab UI at Settings -> Access Tokens) rather than OAuth.
### 5. Send a detailed issue body (optional)
[Section titled “5. Send a detailed issue body (optional)”](#5-send-a-detailed-issue-body-optional)
By default, Honeybadger creates GitLab issues with a short backtrace excerpt and a link back to the fault in Honeybadger. Enable **Send a detailed issue body** to instead create issues with a full Markdown body that includes context, parameters, and the backtrace. Note that enabling this sends more potentially sensitive fault data to GitLab.
### 6. Save
[Section titled “6. Save”](#6-save)
That’s it! You’ll be redirected to GitLab to grant OAuth access (if you left the server URL unchanged), or back to the integrations list if you used a custom server URL and a personal access token. Either way, once you’re back at the integrations list, you can Edit your new GitLab integration and use the Test button to test creating an issue in your repository.
# Google Chat
> Connect Honeybadger to Google Chat to receive real-time application monitoring alerts directly in your team's spaces.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Google Hangouts Chat integration
[Section titled “1. Select the Google Hangouts Chat integration”](#1-select-the-google-hangouts-chat-integration)
 
### 2. Set the webhook URL
[Section titled “2. Set the webhook URL”](#2-set-the-webhook-url)
You can get the Webhook URL by clicking the channel name where you want the notifications to appear in the Hangouts Chat UI:
Choosing the “Add webhooks” option presents a popup that allows you to create a new webhook. You can enter “Honeybadger” for the name, and grab a copy of HB’s [PNG bolt logo](https://honeybadger-static.s3.amazonaws.com/brand_assets/honeybadger_bolt/honeybadger_bolt.png) from our [brand assets page](https://www.honeybadger.io/assets/) for the avatar URL. Saving the webhook generates the webhook URL:
Choose the Copy link button from the actions menu to copy the URL to your clipboard, then enter that url in channel settings in the Honeybadger UI.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
## Honeybadger chat bot
[Section titled “Honeybadger chat bot”](#honeybadger-chat-bot)
If you’d like to install our chat bot in Google Hangouts Chat, search for “Honeybadger” in the “Find people, rooms, bots” search box in the Chat UI. Adding our bot in Chat will prompt you to authorize the bot’s access to your Honeybadger account. Once you do that, you’ll be able to work with your Honeybadger data from within Chat.
# ilert
> Connect Honeybadger to ilert to receive real-time alerts and manage incidents from your on-call workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
[ilert](https://www.ilert.com/) provides alert routing, escalations, and on-call scheduling, ensuring critical issues always reach the right person at the right time. Honeybadger can send events to ilert to trigger alerts when your applications are having problems.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the ilert integration in Honeybadger
[Section titled “1. Select the ilert integration in Honeybadger”](#1-select-the-ilert-integration-in-honeybadger)
 
### 2. Create a Honeybadger alert source in ilert
[Section titled “2. Create a Honeybadger alert source in ilert”](#2-create-a-honeybadger-alert-source-in-ilert)
Follow ilert’s instructions to [create a new alert source for Honeybadger](https://docs.ilert.com/inbound-integrations/honeybadger), and copy the “Honeybadger URL” from the integration settings page.
### 3. Copy/paste the webhook URL from ilert into Honeybadger
[Section titled “3. Copy/paste the webhook URL from ilert into Honeybadger”](#3-copypaste-the-webhook-url-from-ilert-into-honeybadger)
Copy and paste the “Honeybadger URL” from the integration settings page in ilert into the “URL” field in Honeybadger.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test.” Otherwise, just save it and you’re ready to go.
# incident.io
> Connect Honeybadger to incident.io to automatically create incidents from critical errors and manage your response process.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Create an API key in incident.io.
[Section titled “1. Create an API key in incident.io.”](#1-create-an-api-key-in-incidentio)
From your incident.io dashboard, go to Settings > API keys > Add new. Create an API key with the following permissions:
* Create incidents
* Edit incidents
* Create and manage on-call resources
Make sure to copy the generated token.
### 2. In Honeybadger, locate the incident.io integration.
[Section titled “2. In Honeybadger, locate the incident.io integration.”](#2-in-honeybadger-locate-the-incidentio-integration)
In the project settings, click on the **Integrations** tab where you’ll find the incident.io integration.
### 3. Fill in the required fields and save.
[Section titled “3. Fill in the required fields and save.”](#3-fill-in-the-required-fields-and-save)
Fill in API key field with the generated token from step 1 and then specify the alert source label. This will create an alert source in your incident.io account.
### 4. Test the integration.
[Section titled “4. Test the integration.”](#4-test-the-integration)
Click on the “Test this integration” button to send a test notification to your incident.io account. This is a great way to ensure that everything is set up correctly before you start receiving real notifications.
# Instatus
> Connect Honeybadger to Instatus to automatically update your status page when critical errors and application issues are detected.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Instatus integration
[Section titled “1. Select the Instatus integration”](#1-select-the-instatus-integration)
 
### 2. Set the webhook URL
[Section titled “2. Set the webhook URL”](#2-set-the-webhook-url)
Go to Instatus dashboard, under Monitors, select Custom service (webhook). Copy your component’s webhook URL, and then enter that URL into the Webhook URL field in the Honeybadger UI.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Intercom
> Connect Honeybadger to Intercom to track errors affecting specific users and provide better customer support.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Intercom integration
[Section titled “1. Select the Intercom integration”](#1-select-the-intercom-integration)
### 2. Enter your context field
[Section titled “2. Enter your context field”](#2-enter-your-context-field)
This is the field that you set in the context in your application with the user ID that is associated with your Intercom users. For example, if you are identifying users with Intercom with `current_user.id`, and you have `current_user.id` in the `user_id` field of your context, then enter `user_id` in this field.
### 3. Connect via OAuth
[Section titled “3. Connect via OAuth”](#3-connect-via-oauth)
Select the “Connect OAuth” button and give access to our app.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
## What gets sent to Intercom
[Section titled “What gets sent to Intercom”](#what-gets-sent-to-intercom)
When an error occurs, Honeybadger sends an event for the affected user with the following payload:
| Field | Value |
| ------------ | --------------------------------------------------------- |
| `event_name` | `encountered-error` |
| `user_id` | The value from your configured context field (see step 2) |
| `created_at` | Unix timestamp in seconds since the epoch (UTC) |
| `metadata` | `{ "url": "" }` |
You can use this event in Intercom to build segments (e.g. “users who hit an error in the last 7 days”) or to drive a Workflow that sets a custom attribute on the user; for example, flipping a `has_honeybadger_error` attribute to `true` whenever the event fires.
# Jira & Jira Cloud
> Connect Honeybadger to Jira to automatically create tickets from errors and track bug fixes in your project workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
We currently have two different service integrations for Jira. Both versions provide the same features, but differ in the way they authenticate requests.
## Which integration to choose?
[Section titled “Which integration to choose?”](#which-integration-to-choose)
If you are running a Jira Server, then the original [Jira](#jira) Integration is your only option. You *may also* use this integration for Jira Cloud, but we don’t recommend it as it uses Basic Authentication which requires storing credentials to make a API request.
If you are using Jira Cloud, then we highly recommend the newer [Jira Cloud](#jira-cloud) integration as this uses OAuth and only requires us to keep a token for authentication.
## Jira
[Section titled “Jira”](#jira)
### 1. Select the Jira integration
[Section titled “1. Select the Jira integration”](#1-select-the-jira-integration)
 
### 2. Configure
[Section titled “2. Configure”](#2-configure)
Here’s an overview of the options:
* The **username** and **password** will be your login for Jira.
* The **server url** is the subdomain of your Jira instance, such as “”. Don’t forget the “https\://”.
* The **project key** was setup when you created the project. It can be found (on Jira) from Project Overview > Administration > Edit Project.
* The **transition** ID’s can be set in your workflows on Jira when viewed in text mode. ID’s are unique, so make sure there are no conflicting values.
* **Send a detailed issue description** controls how much fault data is included in new issues. By default, Honeybadger sends a short backtrace excerpt and a link back to the fault in Honeybadger. Enable this option to instead send a detailed Jira-wiki description that includes context, parameters, and the backtrace. Note that enabling this sends more potentially sensitive fault data to Jira.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
## Jira Cloud
[Section titled “Jira Cloud”](#jira-cloud)
### 1. Select the Jira Cloud integration
[Section titled “1. Select the Jira Cloud integration”](#1-select-the-jira-cloud-integration)
 
### 2. Configure
[Section titled “2. Configure”](#2-configure-1)
Here’s an overview of the options:
* The **project key** was setup when you created the project. It can be found (on Jira) from Project Overview > Administration > Edit Project.
* The **transition** ID’s can be set in your workflows on Jira when viewed in text mode. ID’s are unique, so make sure there are no conflicting values.
* **Send a detailed issue description** controls how much fault data is included in new issues. By default, Honeybadger sends a short backtrace excerpt and a link back to the fault in Honeybadger. Enable this option to instead send a detailed Jira-wiki description that includes context, parameters, and the backtrace. Note that enabling this sends more potentially sensitive fault data to Jira.
### 3. Save
[Section titled “3. Save”](#3-save-1)
Click “Save” to be sent to Atlassian to authorize our Honeybadger App.
That’s it! Once we have an OAuth connection to your instance you can test the integration clicking “Test”.
# Linear
> Connect Honeybadger to Linear to automatically create issues from errors and track bug fixes in your project workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Linear integration
[Section titled “1. Select the Linear integration”](#1-select-the-linear-integration)
### 2. Connect via OAuth
[Section titled “2. Connect via OAuth”](#2-connect-via-oauth)
An OAuth dialog should appear. Log in to your account, and give access to our app.
### 3. Select team
[Section titled “3. Select team”](#3-select-team)
We gathered all teams associated with your account. Select the team you want to integrate with.
### 4. Project & labels (optional)
[Section titled “4. Project & labels (optional)”](#4-project--labels-optional)
We can associate a project or any labels when we create your issue.
### 5. Unresolved state
[Section titled “5. Unresolved state”](#5-unresolved-state)
This is both the initial and the state that we transition your issue back to if it is reopened.
### 6. Resolved state
[Section titled “6. Resolved state”](#6-resolved-state)
The issue state for resolved errors.
### 7. Save
[Section titled “7. Save”](#7-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Mattermost
> Connect Honeybadger to Mattermost to receive real-time application monitoring alerts directly in your team's chat channels.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Mattermost integration
[Section titled “1. Select the Mattermost integration”](#1-select-the-mattermost-integration)
 
### 2. Set the webhook URL
[Section titled “2. Set the webhook URL”](#2-set-the-webhook-url)
Choose Integrations from the Mattermost sidebar menu, then Incoming Webhooks, and click the “Add Incoming Webhook” button. Enter the options you want, then save the new webhook. Copy the URL displayed on the next page, and then enter that URL into the Webhook URL field in the Honeybadger UI.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Microsoft Teams
> Connect Honeybadger to Microsoft Teams to receive real-time application monitoring alerts in your team collaboration workspace.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Microsoft Teams integration
[Section titled “1. Select the Microsoft Teams integration”](#1-select-the-microsoft-teams-integration)
 
### 2. Set the webhook URL
[Section titled “2. Set the webhook URL”](#2-set-the-webhook-url)
Choose Connectors from the popup channel menu, then Incoming Webhook, and click “Configure” or “Add”. Enter the options you want, then save the new webhook. Copy the provided URL, and then enter that URL into the Webhook URL field in the Honeybadger UI.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# OpsGenie
> Connect Honeybadger to OpsGenie to route critical errors and application issues through your incident management and on-call alerting system.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the OpsGenie integration
[Section titled “1. Select the OpsGenie integration”](#1-select-the-opsgenie-integration)
 
### 2. Set the API key
[Section titled “2. Set the API key”](#2-set-the-api-key)
Caution
Please note that the OpsGenie integration labeled “Honeybadger” is an older version that doesn’t currently support all the events we send.
You can generate a OpsGenie API key by creating an [API Integration](https://support.atlassian.com/opsgenie/docs/create-a-default-api-integration/) by logging in to OpsGenie then going to Settings - Integrations and selecting “API”.
### 3. Select region
[Section titled “3. Select region”](#3-select-region)
We can send to both US and EU regions.
### 4. Select label (optional)
[Section titled “4. Select label (optional)”](#4-select-label-optional)
If you have multiple OpsGenie integrations, you can add a label to differentiate in the integration list view.
### 5. Save
[Section titled “5. Save”](#5-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
## Configuring OpsGenie alerts
[Section titled “Configuring OpsGenie alerts”](#configuring-opsgenie-alerts)
OpsGenie provides the option to route the alerts based on the kind of event that is reported to OpsGenie, and elements from the event payloads can be used in the alert rules. For example, when a check-in fails to report on time, Honeybadger will send the “Check-In Missing” event to OpsGenie. You can use the **Details (key-value)** condition to match that event by specifying “Event” as the **Key** and “Check-In Missing” as the **Value**:
## Event Payloads
[Section titled “Event Payloads”](#event-payloads)
The following events are supported by the OpsGenie integration:
### `Assigned`
[Section titled “Assigned”](#assigned)
Sent when an error is assigned to a user.
**Additional Details keys:** `Error Details`, `Project`, `Environment`, `Assignee Name`, `Assignee Email`
### `Cert Will Expire`
[Section titled “Cert Will Expire”](#cert-will-expire)
Sent when an SSL certificate is about to expire.
**Additional Details keys:** `Project`, `Name`, `URL`
### `Check-In Missing`
[Section titled “Check-In Missing”](#check-in-missing)
Sent when an expected check-in is missing.
**Additional Details keys:** `Check-In Details`, `Project`, `Name`
### `Check-In Reporting`
[Section titled “Check-In Reporting”](#check-in-reporting)
Sent when a check-in reports successfully.
**Additional Details keys:** `Check-In Details`, `Project`, `Name`
### `Commented`
[Section titled “Commented”](#commented)
Sent when a comment is added to an error.
**Additional Details keys:** `Error Details`, `Project`, `Environment`, `Author`
### `Deployed`
[Section titled “Deployed”](#deployed)
Sent when a deployment is recorded.
**Additional Details keys:** `Project`, `Environment`, `Revision`, `Repository`
### `Down`
[Section titled “Down”](#down)
Sent when an uptime check fails.
**Additional Details keys:** `Outage Details`, `Project`, `Name`, `URL`
### `Occurred`
[Section titled “Occurred”](#occurred)
Sent when an error occurs.
**Additional Details keys:** `Error Details`, `Project`, `Environment`
### `Rate Exceeded`
[Section titled “Rate Exceeded”](#rate-exceeded)
Sent when error rate threshold is exceeded.
**Additional Details keys:** `Error Details`, `Project`, `Environment`
### `Resolved`
[Section titled “Resolved”](#resolved)
Sent when an error is marked as resolved.
**Additional Details keys:** `Error Details`, `Project`, `Environment`
### `Unresolved`
[Section titled “Unresolved”](#unresolved)
Sent when a resolved error occurs again.
**Additional Details keys:** `Error Details`, `Project`, `Environment`
### `Up`
[Section titled “Up”](#up)
Sent when an uptime check succeeds after being down.
**Additional Details keys:** `Outage Details`, `Project`, `Name`, `URL`
# PagerDuty
> Connect Honeybadger to PagerDuty to route critical errors and application issues through your incident response workflow and on-call schedules.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the PagerDuty integration
[Section titled “1. Select the PagerDuty integration”](#1-select-the-pagerduty-integration)
 
### 2. Set the API key
[Section titled “2. Set the API key”](#2-set-the-api-key)
You can generate an integration key for Honeybadger by logging in to PagerDuty then clicking on “Add New Service” and choosing “Honeybadger” as the service type. [Here’s a walkthrough](https://www.pagerduty.com/docs/guides/honeybadger-integration-guide/).
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
## Event rules in PagerDuty
[Section titled “Event rules in PagerDuty”](#event-rules-in-pagerduty)
You can use PagerDuty’s [event rules](https://support.pagerduty.com/docs/event-management#section-suppression-and-event-rules) feature to suppress an event or change its severity based on data sent from Honeybadger. For instance, when an exception is sent to PagerDuty, you could set the severity to “critical” for a specific environment when `fault.environment` equals “production”.
The custom data payloads sent from Honeybadger are the same as our [webhook event payloads](/guides/integrations/webhook/#event-payloads).
## Upgrading a legacy PagerDuty integration
[Section titled “Upgrading a legacy PagerDuty integration”](#upgrading-a-legacy-pagerduty-integration)
If your integration is marked “legacy”, then you should upgrade by deleting your existing integration and then creating a new integration following the instructions above. If you use Event Rules in PagerDuty, see the next paragraph.
The custom data payload sent to PagerDuty has changed to match our [webhook event payloads](/guides/integrations/webhook/#event-payloads). If you use [event rules in PagerDuty](#event-rules-in-pagerduty) based on the old payload, you will need to update your rules.
# PagerTree
> Connect Honeybadger to PagerTree to route critical errors and application issues through your incident management and on-call system.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the PagerTree integration
[Section titled “1. Select the PagerTree integration”](#1-select-the-pagertree-integration)
 
### 2. Set the integration URL
[Section titled “2. Set the integration URL”](#2-set-the-integration-url)
Follow the steps outlined in the [PagerTree documentation](https://pagertree.com/knowledge-base/integration-honeybadger/) to get the Endpoint URL. Enter that URL into the URL field in the Honeybadger UI.
### 3. Save
[Section titled “3. Save”](#3-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Error assigned event payload
> Sent when an error is assigned to a user.
Sent when an error is assigned to a user.
```json
{
"event": "assigned",
"message": "[Testy McTestFace/production] ActiveRecord::StatementInvalid assigned to George Jetson by Ben",
"actor": {
"id": 1,
"email": "ben@example.com",
"name": "Ben"
},
"fault": {
"project_id": 123321,
"klass": "ActiveRecord::StatementInvalid",
"component": "search",
"action": "index",
"environment": "production",
"resolved": true,
"ignored": false,
"created_at": "2023-01-31T03:10:01.126549Z",
"comments_count": 3,
"message": "PG::SyntaxError: ERROR: syntax error in tsquery: \"厄瓜多尔Google霸屏【TG飞机:@bapingseo】腾讯视频谷歌完全无广告版【TG飞机:@bapingseo】不到外贸行业运营推广计划怎么写谷歌相机的广告怎么关掉?Em0atRS3g3F4.html\"",
"notices_count": 5514,
"last_notice_at": "2023-02-06T12:20:01.772130Z",
"tags": [],
"id": 42,
"assignee": "george@example.com",
"url": "https://app.honeybadger.io/projects/123321/faults/42",
"deploy": {
"environment": "production",
"revision": "dd2ce1c1f5be3532e10fadf2224a19847f0c62e9",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "heroku-redis@addons.heroku.com",
"created_at": "2023-02-01T05:12:31.417405Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/3e51742fd5f43197891a67b74a54903513e59ce5...dd2ce1c1f5be3532e10fadf2224a19847f0c62e9"
}
},
"assignee": {
"id": 99,
"email": "george@example.com",
"name": "George Jetson"
}
}
```
# Certificate expiration event payload
> Sent when an SSL certificate is about to expire.
Sent when an SSL certificate is about to expire.
```json
{
"event": "cert_will_expire",
"message": "[My Private Project] SSL certificate for gerlach-bergnaum.net will expire on 11/2/2023 11:22:41 UTC",
"project": {
"id": 4,
"name": "My Private Project"
},
"site": {
"id": "f0cacf21-8446-4545-9544-f764b9470c29",
"name": "gerlach-bergnaum.net",
"url": "http://steuber-ernser.com/martha_crona",
"frequency": 5,
"match_type": "success",
"match": null,
"state": "up",
"active": true,
"last_checked_at": "2023-07-21 17:46:24 UTC",
"retries": 0,
"proxy": 0,
"cert_will_expire_at": "2023-11-02 11:22:41 UTC",
"details_url": "http://localhost:3000/projects/4/sites/f0cacf21-8446-4545-9544-f764b9470c29"
}
}
```
# Check-in missing event payload
> Sent when an expected check-in is missing.
Sent when an expected check-in is missing.
```json
{
"event": "check_in_missing",
"message": "[Voyager Test] MISSING: Voyager hasn't checked in for 4 years",
"project": {
"id": 67747,
"name": "Voyager Test",
"created_at": "2019-12-23T21:28:16.571090Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "abcd1234",
"github_project": null,
"environments": [
{
"id": 94721,
"project_id": 67747,
"name": "development",
"notifications": true,
"created_at": "2020-01-08T16:00:02.343155Z",
"updated_at": "2020-01-08T16:00:02.343155Z"
},
{
"id": 94355,
"project_id": 67747,
"name": "local",
"notifications": true,
"created_at": "2019-12-23T21:28:30.733084Z",
"updated_at": "2019-12-23T21:28:30.733084Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2020-11-10T20:07:04.000000Z",
"earliest_notice_at": "2023-05-03T19:39:33.365387Z",
"unresolved_fault_count": 3,
"fault_count": 6,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
}
],
"sites": [],
"team_id": null
},
"check_in": {
"state": "missing",
"schedule_type": "simple",
"reported_at": "2019-12-23T21:39:37.124397Z",
"expected_at": "2023-10-30T19:42:28.853152Z",
"missed_count": 33385,
"grace_period": "00:00:00",
"id": "XYZLOL",
"name": "Voyager",
"slug": null,
"url": "https://api.honeybadger.io/v1/check_in/XYZLOL",
"details_url": "https://app.honeybadger.io/projects/67747/check_ins",
"report_period": "1 hour"
}
}
```
# Check-in reporting event payload
> Sent when a check-in reports successfully.
Sent when a check-in reports successfully.
```json
{
"event": "check_in_reporting",
"message": "[Voyager Test] REPORTING: Voyager is reporting again",
"project": {
"id": 67747,
"name": "Voyager Test",
"created_at": "2019-12-23T21:28:16.571090Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "abcd1234",
"github_project": null,
"environments": [
{
"id": 94721,
"project_id": 67747,
"name": "development",
"notifications": true,
"created_at": "2020-01-08T16:00:02.343155Z",
"updated_at": "2020-01-08T16:00:02.343155Z"
},
{
"id": 94355,
"project_id": 67747,
"name": "local",
"notifications": true,
"created_at": "2019-12-23T21:28:30.733084Z",
"updated_at": "2019-12-23T21:28:30.733084Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2020-11-10T20:07:04.000000Z",
"earliest_notice_at": "2023-05-03T19:39:54.491724Z",
"unresolved_fault_count": 3,
"fault_count": 6,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
}
],
"sites": [],
"team_id": null
},
"check_in": {
"state": "missing",
"schedule_type": "simple",
"reported_at": "2019-12-23T21:39:37.124397Z",
"expected_at": "2023-10-30T19:42:28.853152Z",
"missed_count": 33385,
"grace_period": "00:00:00",
"id": "XYZLOL",
"name": "Voyager",
"slug": null,
"url": "https://api.honeybadger.io/v1/check_in/XYZLOL",
"details_url": "https://app.honeybadger.io/projects/67747/check_ins",
"report_period": "1 hour"
}
}
```
# Error Comment event payload
> Sent when a comment is added to an error.
Sent when a comment is added to an error.
```json
{
"event": "commented",
"message": "[Testy McTestFace/production] Ben commented on ActiveRecord::StatementInvalid: First post!",
"actor": {
"id": 1,
"email": "ben@example.com",
"name": "Ben"
},
"fault": {
"project_id": 123321,
"klass": "ActiveRecord::StatementInvalid",
"component": "search",
"action": "index",
"environment": "production",
"resolved": true,
"ignored": false,
"created_at": "2023-01-31T03:10:01.126549Z",
"comments_count": 3,
"message": "PG::SyntaxError: ERROR: syntax error in tsquery: \"厄瓜多尔Google霸屏【TG飞机:@bapingseo】腾讯视频谷歌完全无广告版【TG飞机:@bapingseo】不到外贸行业运营推广计划怎么写谷歌相机的广告怎么关掉?Em0atRS3g3F4.html\"",
"notices_count": 5514,
"last_notice_at": "2023-02-06T12:20:01.772130Z",
"tags": [],
"id": 42,
"assignee": "george@example.com",
"url": "https://app.honeybadger.io/projects/123321/faults/42",
"deploy": {
"environment": "production",
"revision": "dd2ce1c1f5be3532e10fadf2224a19847f0c62e9",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "heroku-redis@addons.heroku.com",
"created_at": "2023-02-01T05:12:31.417405Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/3e51742fd5f43197891a67b74a54903513e59ce5...dd2ce1c1f5be3532e10fadf2224a19847f0c62e9"
}
},
"comment": {
"id": 7075,
"fault_id": 2653,
"event": null,
"source": "web",
"created_at": "2012-11-29T03:44:09.381543Z",
"email": null,
"author": "Starr",
"body": "You might try shaving the yaks outside of the transaction."
}
}
```
# Deployed event payload
> Sent when a deployment is recorded.
Sent when a deployment is recorded.
```json
{
"event": "deployed",
"message": "[Testy McTestFace/production] ben@example.com deployed Testy McTestFace to production",
"project": {
"id": 123321,
"name": "Testy McTestFace",
"created_at": "2017-08-30T12:54:33.156695Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "zzz111",
"github_project": "spacely/testy-mctestface",
"environments": [
{
"id": 68210,
"project_id": 123321,
"name": "production",
"notifications": true,
"created_at": "2017-09-05T06:10:19.057794Z",
"updated_at": "2017-09-05T06:10:19.057794Z"
},
{
"id": 68074,
"project_id": 123321,
"name": "development",
"notifications": true,
"created_at": "2017-08-30T12:55:29.297392Z",
"updated_at": "2017-08-30T12:55:29.297392Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2023-10-30T19:29:08.000000Z",
"earliest_notice_at": "2023-05-03T19:50:44.677809Z",
"unresolved_fault_count": 102,
"fault_count": 925,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
},
{
"id": 99,
"email": "george@example.com",
"name": "George Jetson"
}
],
"sites": [],
"team_id": 1
},
"deploy": {
"environment": "production",
"revision": "d5b13eea87cd98b45e51b92d6382198f4c102d6d",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "ben@example.com",
"created_at": "2023-10-30T15:10:40.754174Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/5c9c677d9bb17cb3a211d1f65701b866e9ece5a7...d5b13eea87cd98b45e51b92d6382198f4c102d6d"
}
}
```
# Site down event payload
> Sent when an uptime check fails.
Sent when an uptime check fails.
```json
{
"event": "down",
"message": "[Testy McTestFace] Heroku is down.",
"project": {
"id": 123321,
"name": "Testy McTestFace",
"created_at": "2017-08-30T12:54:33.156695Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "zzz111",
"github_project": "spacely/testy-mctestface",
"environments": [
{
"id": 68210,
"project_id": 123321,
"name": "production",
"notifications": true,
"created_at": "2017-09-05T06:10:19.057794Z",
"updated_at": "2017-09-05T06:10:19.057794Z"
},
{
"id": 68074,
"project_id": 123321,
"name": "development",
"notifications": true,
"created_at": "2017-08-30T12:55:29.297392Z",
"updated_at": "2017-08-30T12:55:29.297392Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2023-10-30T19:29:08.000000Z",
"earliest_notice_at": "2023-05-03T19:38:32.092931Z",
"unresolved_fault_count": 102,
"fault_count": 925,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
},
{
"id": 99,
"email": "george@example.com",
"name": "George Jetson"
}
],
"sites": [],
"team_id": 1
},
"site": {
"id": "c42c4c0a-6e3d-4303-9769-549ed2a5818e",
"name": "Heroku",
"url": "https://example.com",
"frequency": 5,
"match_type": "success",
"match": null,
"state": "down",
"active": true,
"last_checked_at": "2023-10-30T19:34:08.150725Z",
"retries": 0,
"proxy": 4,
"cert_will_expire_at": null,
"details_url": "https://app.honeybadger.io/projects/123321/sites/c42c4c0a-6e3d-4303-9769-549ed2a5818e"
},
"outage": {
"down_at": "2023-07-17T15:46:52.384701Z",
"up_at": "2023-07-17T15:51:56.063948Z",
"status": null,
"reason": "Connection timed out",
"headers": null,
"details_url": "https://app.honeybadger.io/projects/123321/sites/c42c4c0a-6e3d-4303-9769-549ed2a5818e"
}
}
```
# Occurred event payload
> Sent when an error occurs.
Sent when an error occurs.
```json
{
"event": "occurred",
"message": "[Testy McTestFace/production] ActiveRecord::NoDatabaseError: We could not find your database: d6ipl26lboesdi. Which can be found in the database configuration file located at config/database.yml.\n\nTo resolve this issue:\n\n- Did you create the database for th...",
"project": {
"id": 123321,
"name": "Testy McTestFace",
"created_at": "2017-08-30T12:54:33.156695Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "zzz111",
"github_project": "spacely/testy-mctestface",
"environments": [
{
"id": 68210,
"project_id": 123321,
"name": "production",
"notifications": true,
"created_at": "2017-09-05T06:10:19.057794Z",
"updated_at": "2017-09-05T06:10:19.057794Z"
},
{
"id": 68074,
"project_id": 123321,
"name": "development",
"notifications": true,
"created_at": "2017-08-30T12:55:29.297392Z",
"updated_at": "2017-08-30T12:55:29.297392Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2023-10-30T19:29:08.000000Z",
"earliest_notice_at": "2023-05-03T19:35:56.783102Z",
"unresolved_fault_count": 102,
"fault_count": 925,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
},
{
"id": 99,
"email": "george@example.com",
"name": "George Jetson"
}
],
"sites": [
{
"id": "c42c4c0a-6e3d-4303-9769-549ed2a5818e",
"active": true,
"last_checked_at": "2023-10-30T19:34:08.150725Z",
"name": "Heroku",
"state": "up",
"url": "https://example.com"
}
],
"team_id": 1
},
"fault": {
"project_id": 123321,
"klass": "ActiveRecord::NoDatabaseError",
"component": "pages",
"action": "home",
"environment": "production",
"resolved": false,
"ignored": false,
"created_at": "2023-10-13T18:07:55.692256Z",
"comments_count": 0,
"message": "We could not find your database: d6ipl26lboesdi. Which can be found in the database configuration file located at config/database.yml.\n\nTo resolve this issue:\n\n- Did you create the database for this app, or delete it? You may need to create your database.\n- Has the database name changed? Check your database.yml config has the correct database name.\n\nTo create your database, run:\n\n bin/rails db:create",
"notices_count": 6,
"last_notice_at": "2023-10-13T18:08:10.000000Z",
"tags": [],
"id": 101337516,
"assignee": null,
"url": "https://app.honeybadger.io/projects/123321/faults/101337516",
"deploy": {
"environment": "production",
"revision": "0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "ben@example.com",
"created_at": "2023-10-06T20:52:51.878336Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/d4f90c876adf4a108ebb9a6f47b5562b59578d97...0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba"
}
},
"notice": {
"id": 1013375161697220500,
"environment": {},
"created_at": "2023-10-13T18:08:10.141219Z",
"message": null,
"token": "babe1d9d-67e3-4438-8c57-c544cea24ffb",
"fault_id": 101337516,
"request": {
"url": "https://example.com/",
"component": "pages",
"action": "home",
"params": {
"controller": "pages",
"action": "home"
},
"session": {},
"context": {}
},
"backtrace": [
{
"number": "81",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/postgresql_adapter.rb",
"method": "rescue in new_client",
"source": {
"79": " rescue ::PG::Error => error\n",
"80": " if conn_params && conn_params[:dbname] && error.message.include?(conn_params[:dbname])\n",
"81": " raise ActiveRecord::NoDatabaseError.db_error(conn_params[:dbname])\n",
"82": " elsif conn_params && conn_params[:user] && error.message.include?(conn_params[:user])\n",
"83": " raise ActiveRecord::DatabaseConnectionError.username_error(conn_params[:user])\n"
},
"context": "all"
},
{
"number": "77",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/postgresql_adapter.rb",
"method": "new_client",
"source": {
"75": "\n",
"76": " class << self\n",
"77": " def new_client(conn_params)\n",
"78": " PG.connect(**conn_params)\n",
"79": " rescue ::PG::Error => error\n"
},
"context": "all"
},
{
"number": "37",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/postgresql_adapter.rb",
"method": "postgresql_connection",
"source": {
"35": "\n",
"36": " ConnectionAdapters::PostgreSQLAdapter.new(\n",
"37": " ConnectionAdapters::PostgreSQLAdapter.new_client(conn_params),\n",
"38": " logger,\n",
"39": " conn_params,\n"
},
"context": "all"
},
{
"number": "656",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "public_send",
"source": {
"654": "\n",
"655": " def new_connection\n",
"656": " Base.public_send(db_config.adapter_method, db_config.configuration_hash).tap do |conn|\n",
"657": " conn.check_version\n",
"658": " end\n"
},
"context": "all"
},
{
"number": "656",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "new_connection",
"source": {
"654": "\n",
"655": " def new_connection\n",
"656": " Base.public_send(db_config.adapter_method, db_config.configuration_hash).tap do |conn|\n",
"657": " conn.check_version\n",
"658": " end\n"
},
"context": "all"
},
{
"number": "700",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "checkout_new_connection",
"source": {
"698": " def checkout_new_connection\n",
"699": " raise ConnectionNotEstablished unless @automatic_reconnect\n",
"700": " new_connection\n",
"701": " end\n",
"702": "\n"
},
"context": "all"
},
{
"number": "679",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "try_to_checkout_new_connection",
"source": {
"677": " # if successfully incremented @now_connecting establish new connection\n",
"678": " # outside of synchronized section\n",
"679": " conn = checkout_new_connection\n",
"680": " ensure\n",
"681": " synchronize do\n"
},
"context": "all"
},
{
"number": "640",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "acquire_connection",
"source": {
"638": " # and +try_to_checkout_new_connection+ we can piggyback on +synchronize+ sections\n",
"639": " # of the said methods and avoid an additional +synchronize+ overhead.\n",
"640": " if conn = @available.poll || try_to_checkout_new_connection\n",
"641": " conn\n",
"642": " else\n"
},
"context": "all"
},
{
"number": "341",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "checkout",
"source": {
"339": " # - ActiveRecord::ConnectionTimeoutError no connection can be obtained from the pool.\n",
"340": " def checkout(checkout_timeout = @checkout_timeout)\n",
"341": " checkout_and_verify(acquire_connection(checkout_timeout))\n",
"342": " end\n",
"343": "\n"
},
"context": "all"
},
{
"number": "181",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "connection",
"source": {
"179": " # held in a cache keyed by a thread.\n",
"180": " def connection\n",
"181": " @thread_cached_conns[connection_cache_key(current_thread)] ||= checkout\n",
"182": " end\n",
"183": "\n"
},
"context": "all"
},
{
"number": "211",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_handler.rb",
"method": "retrieve_connection",
"source": {
"209": " end\n",
"210": "\n",
"211": " pool.connection\n",
"212": " end\n",
"213": "\n"
},
"context": "all"
},
{
"number": "313",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_handling.rb",
"method": "retrieve_connection",
"source": {
"311": "\n",
"312": " def retrieve_connection\n",
"313": " connection_handler.retrieve_connection(connection_specification_name, role: current_role, shard: current_shard)\n",
"314": " end\n",
"315": "\n"
},
"context": "all"
},
{
"number": "280",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_handling.rb",
"method": "connection",
"source": {
"278": " # to any of the specific Active Records.\n",
"279": " def connection\n",
"280": " retrieve_connection\n",
"281": " end\n",
"282": "\n"
},
"context": "all"
},
{
"number": "433",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/core.rb",
"method": "cached_find_by_statement",
"source": {
"431": "\n",
"432": " def cached_find_by_statement(key, &block) # :nodoc:\n",
"433": " cache = @find_by_statement_cache[connection.prepared_statements]\n",
"434": " cache.compute_if_absent(key) { StatementCache.create(connection, &block) }\n",
"435": " end\n"
},
"context": "all"
},
{
"number": "317",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/core.rb",
"method": "find_by",
"source": {
"315": "\n",
"316": " keys = hash.keys\n",
"317": " statement = cached_find_by_statement(keys) { |params|\n",
"318": " wheres = keys.index_with { params.bind }\n",
"319": " where(wheres).limit(1)\n"
},
"context": "all"
},
{
"number": "69",
"file": "[PROJECT_ROOT]/app/controllers/application_controller.rb",
"method": "check_redirect",
"source": {
"67": "\n",
"68": " def check_redirect\n",
"69": " return unless (redirect = Redirect.find_by(slug: request.path.sub(%r{^/}, \"\")))\n",
"70": " redirect_to redirect.url\n",
"71": " end\n"
},
"application_file": "app/controllers/application_controller.rb",
"context": "app"
},
{
"number": "400",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block in make_lambda",
"source": {
"398": " def make_lambda\n",
"399": " lambda do |target, value, &block|\n",
"400": " target.send(@method_name, &block)\n",
"401": " end\n",
"402": " end\n"
},
"context": "all"
},
{
"number": "180",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block (2 levels) in halting_and_conditional",
"source": {
"178": "\n",
"179": " if !halted && user_conditions.all? { |c| c.call(target, value) }\n",
"180": " result_lambda = -> { user_callback.call target, value }\n",
"181": " env.halted = halted_lambda.call(target, result_lambda)\n",
"182": " if env.halted\n"
},
"context": "all"
},
{
"number": "34",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/abstract_controller/callbacks.rb",
"method": "block (2 levels) in ",
"source": {
"32": " included do\n",
"33": " define_callbacks :process_action,\n",
"34": " terminator: ->(controller, result_lambda) { result_lambda.call; controller.performed? },\n",
"35": " skip_after_callbacks_if_terminated: true\n",
"36": " end\n"
},
"context": "all"
},
{
"number": "181",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block in halting_and_conditional",
"source": {
"179": " if !halted && user_conditions.all? { |c| c.call(target, value) }\n",
"180": " result_lambda = -> { user_callback.call target, value }\n",
"181": " env.halted = halted_lambda.call(target, result_lambda)\n",
"182": " if env.halted\n",
"183": " target.send :halted_callback_hook, filter, name\n"
},
"context": "all"
},
{
"number": "595",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block in invoke_before",
"source": {
"593": "\n",
"594": " def invoke_before(arg)\n",
"595": " @before.each { |b| b.call(arg) }\n",
"596": " end\n",
"597": "\n"
},
"context": "all"
},
{
"number": "595",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "each",
"source": {
"593": "\n",
"594": " def invoke_before(arg)\n",
"595": " @before.each { |b| b.call(arg) }\n",
"596": " end\n",
"597": "\n"
},
"context": "all"
},
{
"number": "595",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "invoke_before",
"source": {
"593": "\n",
"594": " def invoke_before(arg)\n",
"595": " @before.each { |b| b.call(arg) }\n",
"596": " end\n",
"597": "\n"
},
"context": "all"
},
{
"number": "106",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "run_callbacks",
"source": {
"104": " # Common case: no 'around' callbacks defined\n",
"105": " if next_sequence.final?\n",
"106": " next_sequence.invoke_before(env)\n",
"107": " env.value = !env.halted && (!block_given? || yield)\n",
"108": " next_sequence.invoke_after(env)\n"
},
"context": "all"
},
{
"number": "233",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/abstract_controller/callbacks.rb",
"method": "process_action",
"source": {
"231": " # process_action callbacks around the normal behavior.\n",
"232": " def process_action(...)\n",
"233": " run_callbacks(:process_action) do\n",
"234": " super\n",
"235": " end\n"
},
"context": "all"
},
{
"number": "23",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/rescue.rb",
"method": "process_action",
"source": {
"21": " private\n",
"22": " def process_action(*)\n",
"23": " super\n",
"24": " rescue Exception => exception\n",
"25": " request.env[\"action_dispatch.show_detailed_exceptions\"] ||= show_detailed_exceptions?\n"
},
"context": "all"
},
{
"number": "67",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/instrumentation.rb",
"method": "block in process_action",
"source": {
"65": "\n",
"66": " ActiveSupport::Notifications.instrument(\"process_action.action_controller\", raw_payload) do |payload|\n",
"67": " result = super\n",
"68": " payload[:response] = response\n",
"69": " payload[:status] = response.status\n"
},
"context": "all"
},
{
"number": "206",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/notifications.rb",
"method": "block in instrument",
"source": {
"204": " def instrument(name, payload = {})\n",
"205": " if notifier.listening?(name)\n",
"206": " instrumenter.instrument(name, payload) { yield payload if block_given? }\n",
"207": " else\n",
"208": " yield payload if block_given?\n"
},
"context": "all"
},
{
"number": "24",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/notifications/instrumenter.rb",
"method": "instrument",
"source": {
"22": " listeners_state = start name, payload\n",
"23": " begin\n",
"24": " yield payload if block_given?\n",
"25": " rescue Exception => e\n",
"26": " payload[:exception] = [e.class.name, e.message]\n"
},
"context": "all"
},
{
"number": "206",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/notifications.rb",
"method": "instrument",
"source": {
"204": " def instrument(name, payload = {})\n",
"205": " if notifier.listening?(name)\n",
"206": " instrumenter.instrument(name, payload) { yield payload if block_given? }\n",
"207": " else\n",
"208": " yield payload if block_given?\n"
},
"context": "all"
},
{
"number": "66",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/instrumentation.rb",
"method": "process_action",
"source": {
"64": " ActiveSupport::Notifications.instrument(\"start_processing.action_controller\", raw_payload)\n",
"65": "\n",
"66": " ActiveSupport::Notifications.instrument(\"process_action.action_controller\", raw_payload) do |payload|\n",
"67": " result = super\n",
"68": " payload[:response] = response\n"
},
"context": "all"
},
{
"number": "259",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/params_wrapper.rb",
"method": "process_action",
"source": {
"257": " def process_action(*)\n",
"258": " _perform_parameter_wrapping if _wrapper_enabled?\n",
"259": " super\n",
"260": " end\n",
"261": "\n"
},
"context": "all"
},
{
"number": "27",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/railties/controller_runtime.rb",
"method": "process_action",
"source": {
"25": " # and it won't be cleaned up by the method below.\n",
"26": " ActiveRecord::LogSubscriber.reset_runtime\n",
"27": " super\n",
"28": " end\n",
"29": "\n"
},
"context": "all"
},
{
"number": "120",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/instruments/action_controller_rails_3_rails4.rb",
"method": "process_action",
"source": {
"118": " req.start_layer( ScoutApm::Layer.new(\"Controller\", \"#{controller_path}/#{resolved_name}\") )\n",
"119": " begin\n",
"120": " super\n",
"121": " rescue\n",
"122": " req.error!\n"
},
"context": "all"
},
{
"number": "151",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/abstract_controller/base.rb",
"method": "process",
"source": {
"149": " @_response_body = nil\n",
"150": "\n",
"151": " process_action(action_name, *args)\n",
"152": " end\n",
"153": " ruby2_keywords(:process)\n"
},
"context": "all"
},
{
"number": "39",
"file": "[GEM_ROOT]/gems/actionview-7.0.7.2/lib/action_view/rendering.rb",
"method": "process",
"source": {
"37": " def process(...) # :nodoc:\n",
"38": " old_config, I18n.config = I18n.config, I18nProxy.new(I18n.config, lookup_context)\n",
"39": " super\n",
"40": " ensure\n",
"41": " I18n.config = old_config\n"
},
"context": "all"
},
{
"number": "188",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal.rb",
"method": "dispatch",
"source": {
"186": " set_request!(request)\n",
"187": " set_response!(response)\n",
"188": " process(name)\n",
"189": " request.commit_flash\n",
"190": " to_a\n"
},
"context": "all"
},
{
"number": "251",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal.rb",
"method": "dispatch",
"source": {
"249": " middleware_stack.build(name) { |env| new.dispatch(name, req, res) }.call req.env\n",
"250": " else\n",
"251": " new.dispatch(name, req, res)\n",
"252": " end\n",
"253": " end\n"
},
"context": "all"
},
{
"number": "49",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/routing/route_set.rb",
"method": "dispatch",
"source": {
"47": "\n",
"48": " def dispatch(controller, action, req, res)\n",
"49": " controller.dispatch(action, req, res)\n",
"50": " end\n",
"51": " end\n"
},
"context": "all"
},
{
"number": "32",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/routing/route_set.rb",
"method": "serve",
"source": {
"30": " controller = controller req\n",
"31": " res = controller.make_response! req\n",
"32": " dispatch(controller, params[:action], req, res)\n",
"33": " rescue ActionController::RoutingError\n",
"34": " if @raise_on_name_error\n"
},
"context": "all"
},
{
"number": "50",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/journey/router.rb",
"method": "block in serve",
"source": {
"48": " req.path_parameters = tmp_params\n",
"49": "\n",
"50": " status, headers, body = route.app.serve(req)\n",
"51": "\n",
"52": " if \"pass\" == headers[\"X-Cascade\"]\n"
},
"context": "all"
},
{
"number": "32",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/journey/router.rb",
"method": "each",
"source": {
"30": "\n",
"31": " def serve(req)\n",
"32": " find_routes(req).each do |match, parameters, route|\n",
"33": " set_params = req.path_parameters\n",
"34": " path_info = req.path_info\n"
},
"context": "all"
},
{
"number": "32",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/journey/router.rb",
"method": "serve",
"source": {
"30": "\n",
"31": " def serve(req)\n",
"32": " find_routes(req).each do |match, parameters, route|\n",
"33": " set_params = req.path_parameters\n",
"34": " path_info = req.path_info\n"
},
"context": "all"
},
{
"number": "852",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/routing/route_set.rb",
"method": "call",
"source": {
"850": " req = make_request(env)\n",
"851": " req.path_info = Journey::Router::Utils.normalize_path(req.path_info)\n",
"852": " @router.serve(req)\n",
"853": " end\n",
"854": "\n"
},
"context": "all"
},
{
"number": "29",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/instruments/rails_router.rb",
"method": "call_with_scout_instruments",
"source": {
"27": "\n",
"28": " begin\n",
"29": " call_without_scout_instruments(*args)\n",
"30": " ensure\n",
"31": " req.stop_layer\n"
},
"context": "all"
},
{
"number": "17",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/middleware.rb",
"method": "call",
"source": {
"15": " def call(env)\n",
"16": " if !@enabled || @started || @attempts > MAX_ATTEMPTS\n",
"17": " @app.call(env)\n",
"18": " else\n",
"19": " attempt_to_start_agent\n"
},
"context": "all"
},
{
"number": "36",
"file": "[GEM_ROOT]/gems/warden-1.2.9/lib/warden/manager.rb",
"method": "block in call",
"source": {
"34": " result = catch(:warden) do\n",
"35": " env['warden'].on_request\n",
"36": " @app.call(env)\n",
"37": " end\n",
"38": "\n"
},
"context": "all"
},
{
"number": "34",
"file": "[GEM_ROOT]/gems/warden-1.2.9/lib/warden/manager.rb",
"method": "catch",
"source": {
"32": "\n",
"33": " env['warden'] = Proxy.new(env, self)\n",
"34": " result = catch(:warden) do\n",
"35": " env['warden'].on_request\n",
"36": " @app.call(env)\n"
},
"context": "all"
},
{
"number": "34",
"file": "[GEM_ROOT]/gems/warden-1.2.9/lib/warden/manager.rb",
"method": "call",
"source": {
"32": "\n",
"33": " env['warden'] = Proxy.new(env, self)\n",
"34": " result = catch(:warden) do\n",
"35": " env['warden'].on_request\n",
"36": " @app.call(env)\n"
},
"context": "all"
},
{
"number": "15",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/tempfile_reaper.rb",
"method": "call",
"source": {
"13": " def call(env)\n",
"14": " env[RACK_TEMPFILES] ||= []\n",
"15": " status, headers, body = @app.call(env)\n",
"16": " body_proxy = BodyProxy.new(body) do\n",
"17": " env[RACK_TEMPFILES].each(&:close!) unless env[RACK_TEMPFILES].nil?\n"
},
"context": "all"
},
{
"number": "27",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/conditional_get.rb",
"method": "call",
"source": {
"25": " case env[REQUEST_METHOD]\n",
"26": " when \"GET\", \"HEAD\"\n",
"27": " status, headers, body = @app.call(env)\n",
"28": " headers = Utils::HeaderHash[headers]\n",
"29": " if status == 200 && fresh?(env, headers)\n"
},
"context": "all"
},
{
"number": "12",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/head.rb",
"method": "call",
"source": {
"10": "\n",
"11": " def call(env)\n",
"12": " status, headers, body = @app.call(env)\n",
"13": "\n",
"14": " if env[REQUEST_METHOD] == HEAD\n"
},
"context": "all"
},
{
"number": "38",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/http/permissions_policy.rb",
"method": "call",
"source": {
"36": " def call(env)\n",
"37": " request = ActionDispatch::Request.new(env)\n",
"38": " _, headers, _ = response = @app.call(env)\n",
"39": "\n",
"40": " return response unless html_response?(headers)\n"
},
"context": "all"
},
{
"number": "36",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/http/content_security_policy.rb",
"method": "call",
"source": {
"34": " def call(env)\n",
"35": " request = ActionDispatch::Request.new env\n",
"36": " status, headers, _ = response = @app.call(env)\n",
"37": "\n",
"38": " # Returning CSP headers with a 304 Not Modified is harmful, since nonces in the new\n"
},
"context": "all"
},
{
"number": "266",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/session/abstract/id.rb",
"method": "context",
"source": {
"264": " req = make_request env\n",
"265": " prepare_session(req)\n",
"266": " status, headers, body = app.call(req.env)\n",
"267": " res = Rack::Response::Raw.new status, headers\n",
"268": " commit_session(req, res)\n"
},
"context": "all"
},
{
"number": "260",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/session/abstract/id.rb",
"method": "call",
"source": {
"258": "\n",
"259": " def call(env)\n",
"260": " context(env)\n",
"261": " end\n",
"262": "\n"
},
"context": "all"
},
{
"number": "704",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/cookies.rb",
"method": "call",
"source": {
"702": " request = ActionDispatch::Request.new env\n",
"703": "\n",
"704": " status, headers, body = @app.call(env)\n",
"705": "\n",
"706": " if request.have_cookie_jar?\n"
},
"context": "all"
},
{
"number": "27",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/callbacks.rb",
"method": "block in call",
"source": {
"25": " error = nil\n",
"26": " result = run_callbacks :call do\n",
"27": " @app.call(env)\n",
"28": " rescue => error\n",
"29": " end\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "run_callbacks",
"source": {
"97": "\n",
"98": " if callbacks.empty?\n",
"99": " yield if block_given?\n",
"100": " else\n",
"101": " env = Filters::Environment.new(self, false, nil)\n"
},
"context": "all"
},
{
"number": "26",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/callbacks.rb",
"method": "call",
"source": {
"24": " def call(env)\n",
"25": " error = nil\n",
"26": " result = run_callbacks :call do\n",
"27": " @app.call(env)\n",
"28": " rescue => error\n"
},
"context": "all"
},
{
"number": "28",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/debug_exceptions.rb",
"method": "call",
"source": {
"26": " def call(env)\n",
"27": " request = ActionDispatch::Request.new env\n",
"28": " _, headers, body = response = @app.call(env)\n",
"29": "\n",
"30": " if headers[\"X-Cascade\"] == \"pass\"\n"
},
"context": "all"
},
{
"number": "29",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/show_exceptions.rb",
"method": "call",
"source": {
"27": " def call(env)\n",
"28": " request = ActionDispatch::Request.new env\n",
"29": " @app.call(env)\n",
"30": " rescue Exception => exception\n",
"31": " if request.show_exceptions?\n"
},
"context": "all"
},
{
"number": "18",
"file": "[GEM_ROOT]/gems/lograge-0.12.0/lib/lograge/rails_ext/rack/logger.rb",
"method": "call_app",
"source": {
"16": " def call_app(*args)\n",
"17": " env = args.last\n",
"18": " status, headers, body = @app.call(env)\n",
"19": " # needs to have same return type as the Rails builtins being overridden, see https://github.com/roidrage/lograge/pull/333\n",
"20": " # https://github.com/rails/rails/blob/be9d34b9bcb448b265114ebc28bef1a5b5e4c272/railties/lib/rails/rack/logger.rb#L37\n"
},
"context": "all"
},
{
"number": "25",
"file": "[GEM_ROOT]/gems/railties-7.0.7.2/lib/rails/rack/logger.rb",
"method": "block in call",
"source": {
"23": "\n",
"24": " if logger.respond_to?(:tagged)\n",
"25": " logger.tagged(compute_tags(request)) { call_app(request, env) }\n",
"26": " else\n",
"27": " call_app(request, env)\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/tagged_logging.rb",
"method": "block in tagged",
"source": {
"97": " def tagged(*tags)\n",
"98": " if block_given?\n",
"99": " formatter.tagged(*tags) { yield self }\n",
"100": " else\n",
"101": " logger = ActiveSupport::TaggedLogging.new(self)\n"
},
"context": "all"
},
{
"number": "37",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/tagged_logging.rb",
"method": "tagged",
"source": {
"35": " def tagged(*tags)\n",
"36": " new_tags = push_tags(*tags)\n",
"37": " yield self\n",
"38": " ensure\n",
"39": " pop_tags(new_tags.size)\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/tagged_logging.rb",
"method": "tagged",
"source": {
"97": " def tagged(*tags)\n",
"98": " if block_given?\n",
"99": " formatter.tagged(*tags) { yield self }\n",
"100": " else\n",
"101": " logger = ActiveSupport::TaggedLogging.new(self)\n"
},
"context": "all"
},
{
"number": "25",
"file": "[GEM_ROOT]/gems/railties-7.0.7.2/lib/rails/rack/logger.rb",
"method": "call",
"source": {
"23": "\n",
"24": " if logger.respond_to?(:tagged)\n",
"25": " logger.tagged(compute_tags(request)) { call_app(request, env) }\n",
"26": " else\n",
"27": " call_app(request, env)\n"
},
"context": "all"
},
{
"number": "93",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/remote_ip.rb",
"method": "call",
"source": {
"91": " req = ActionDispatch::Request.new env\n",
"92": " req.remote_ip = GetIp.new(req, check_ip, proxies)\n",
"93": " @app.call(req.env)\n",
"94": " end\n",
"95": "\n"
},
"context": "all"
},
{
"number": "19",
"file": "[GEM_ROOT]/gems/request_store-1.5.1/lib/request_store/middleware.rb",
"method": "call",
"source": {
"17": " RequestStore.begin!\r\n",
"18": "\r\n",
"19": " status, headers, body = @app.call(env)\r\n",
"20": "\r\n",
"21": " body = Rack::BodyProxy.new(body) do\r\n"
},
"context": "all"
},
{
"number": "26",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/request_id.rb",
"method": "call",
"source": {
"24": " req = ActionDispatch::Request.new env\n",
"25": " req.request_id = make_request_id(req.headers[@header])\n",
"26": " @app.call(env).tap { |_status, headers, _body| headers[@header] = req.request_id }\n",
"27": " end\n",
"28": "\n"
},
"context": "all"
},
{
"number": "24",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/method_override.rb",
"method": "call",
"source": {
"22": " end\n",
"23": "\n",
"24": " @app.call(env)\n",
"25": " end\n",
"26": "\n"
},
"context": "all"
},
{
"number": "22",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/runtime.rb",
"method": "call",
"source": {
"20": " def call(env)\n",
"21": " start_time = Utils.clock_time\n",
"22": " status, headers, body = @app.call(env)\n",
"23": " headers = Utils::HeaderHash[headers]\n",
"24": "\n"
},
"context": "all"
},
{
"number": "148",
"file": "[GEM_ROOT]/gems/rack-timeout-0.6.3/lib/rack/timeout/core.rb",
"method": "block in call",
"source": {
"146": "\n",
"147": " response = timeout.timeout(info.timeout) do # perform request with timeout\n",
"148": " begin @app.call(env) # boom, send request down the middleware chain\n",
"149": " rescue RequestTimeoutException => e # will actually hardly ever get to this point because frameworks tend to catch this. see README for more\n",
"150": " raise RequestTimeoutError.new(env), e.message, e.backtrace # but in case it does get here, re-raise RequestTimeoutException as RequestTimeoutError\n"
},
"context": "all"
},
{
"number": "19",
"file": "[GEM_ROOT]/gems/rack-timeout-0.6.3/lib/rack/timeout/support/timeout.rb",
"method": "timeout",
"source": {
"17": " thr = Thread.current # reference to current thread to be used in timeout thread\n",
"18": " job = @scheduler.run_in(secs) { @on_timeout.call thr } # schedule this thread to be timed out; should get cancelled if block completes on time\n",
"19": " return block.call # do what you gotta do\n",
"20": " ensure #\n",
"21": " job.cancel! if job # cancel the scheduled timeout job; if the block completed on time, this\n"
},
"context": "all"
},
{
"number": "147",
"file": "[GEM_ROOT]/gems/rack-timeout-0.6.3/lib/rack/timeout/core.rb",
"method": "call",
"source": {
"145": " end\n",
"146": "\n",
"147": " response = timeout.timeout(info.timeout) do # perform request with timeout\n",
"148": " begin @app.call(env) # boom, send request down the middleware chain\n",
"149": " rescue RequestTimeoutException => e # will actually hardly ever get to this point because frameworks tend to catch this. see README for more\n"
},
"context": "all"
},
{
"number": "41",
"file": "[GEM_ROOT]/gems/judoscale-ruby-1.4.1/lib/judoscale/request_middleware.rb",
"method": "call",
"source": {
"39": " end\n",
"40": "\n",
"41": " @app.call(env)\n",
"42": " end\n",
"43": " end\n"
},
"context": "all"
},
{
"number": "29",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/cache/strategy/local_cache_middleware.rb",
"method": "call",
"source": {
"27": " def call(env)\n",
"28": " LocalCacheRegistry.set_cache_for(local_cache_key, LocalStore.new)\n",
"29": " response = @app.call(env)\n",
"30": " response[2] = ::Rack::BodyProxy.new(response[2]) do\n",
"31": " LocalCacheRegistry.set_cache_for(local_cache_key, nil)\n"
},
"context": "all"
},
{
"number": "24",
"file": "[GEM_ROOT]/gems/rack-rewrite-1.5.1/lib/rack/rewrite.rb",
"method": "call",
"source": {
"22": " return rack_response unless rack_response === true\n",
"23": " end\n",
"24": " @app.call(env)\n",
"25": " end\n",
"26": " \n"
},
"context": "all"
},
{
"number": "14",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/executor.rb",
"method": "call",
"source": {
"12": " state = @executor.run!(reset: true)\n",
"13": " begin\n",
"14": " response = @app.call(env)\n",
"15": " returned = response << ::Rack::BodyProxy.new(response.pop) { state.complete! }\n",
"16": " rescue => error\n"
},
"context": "all"
},
{
"number": "23",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/static.rb",
"method": "call",
"source": {
"21": "\n",
"22": " def call(env)\n",
"23": " @file_handler.attempt(env) || @app.call(env)\n",
"24": " end\n",
"25": " end\n"
},
"context": "all"
},
{
"number": "110",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/sendfile.rb",
"method": "call",
"source": {
"108": "\n",
"109": " def call(env)\n",
"110": " status, headers, body = @app.call(env)\n",
"111": " if body.respond_to?(:to_path)\n",
"112": " case type = variation(env)\n"
},
"context": "all"
},
{
"number": "77",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/ssl.rb",
"method": "call",
"source": {
"75": "\n",
"76": " if request.ssl?\n",
"77": " @app.call(env).tap do |status, headers, body|\n",
"78": " set_hsts_header! headers\n",
"79": " flag_cookies_as_secure! headers if @secure_cookies && !@exclude.call(request)\n"
},
"context": "all"
},
{
"number": "131",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/host_authorization.rb",
"method": "call",
"source": {
"129": "\n",
"130": " def call(env)\n",
"131": " return @app.call(env) if @permissions.empty?\n",
"132": "\n",
"133": " request = Request.new(env)\n"
},
"context": "all"
},
{
"number": "58",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/instruments/middleware_summary.rb",
"method": "call",
"source": {
"56": " layer = ScoutApm::Layer.new(\"Middleware\", \"Summary\")\n",
"57": " req.start_layer(layer)\n",
"58": " @app.call(env)\n",
"59": " ensure\n",
"60": " req.stop_layer\n"
},
"context": "all"
},
{
"number": "530",
"file": "[GEM_ROOT]/gems/railties-7.0.7.2/lib/rails/engine.rb",
"method": "call",
"source": {
"528": " def call(env)\n",
"529": " req = build_request env\n",
"530": " app.call req.env\n",
"531": " end\n",
"532": "\n"
},
"context": "all"
},
{
"number": "270",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/configuration.rb",
"method": "call",
"source": {
"268": " def call(env)\n",
"269": " env[Const::PUMA_CONFIG] = @config\n",
"270": " @app.call(env)\n",
"271": " end\n",
"272": " end\n"
},
"context": "all"
},
{
"number": "100",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/request.rb",
"method": "block in handle_request",
"source": {
"98": " if @supported_http_methods == :any || @supported_http_methods.key?(env[REQUEST_METHOD])\n",
"99": " status, headers, app_body = @thread_pool.with_force_shutdown do\n",
"100": " @app.call(env)\n",
"101": " end\n",
"102": " else\n"
},
"context": "all"
},
{
"number": "344",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/thread_pool.rb",
"method": "with_force_shutdown",
"source": {
"342": " t[:with_force_shutdown] = true\n",
"343": " end\n",
"344": " yield\n",
"345": " ensure\n",
"346": " t[:with_force_shutdown] = false\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/request.rb",
"method": "handle_request",
"source": {
"97": " begin\n",
"98": " if @supported_http_methods == :any || @supported_http_methods.key?(env[REQUEST_METHOD])\n",
"99": " status, headers, app_body = @thread_pool.with_force_shutdown do\n",
"100": " @app.call(env)\n",
"101": " end\n"
},
"context": "all"
},
{
"number": "443",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/server.rb",
"method": "process_client",
"source": {
"441": " while true\n",
"442": " @requests_count += 1\n",
"443": " case handle_request(client, requests + 1)\n",
"444": " when false\n",
"445": " break\n"
},
"context": "all"
},
{
"number": "245",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/server.rb",
"method": "block in run",
"source": {
"243": " @status = :run\n",
"244": "\n",
"245": " @thread_pool = ThreadPool.new(thread_name, @options) { |client| process_client client }\n",
"246": "\n",
"247": " if @queue_requests\n"
},
"context": "all"
},
{
"number": "151",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/thread_pool.rb",
"method": "block in spawn_thread",
"source": {
"149": "\n",
"150": " begin\n",
"151": " @out_of_band_pending = true if block.call(work)\n",
"152": " rescue Exception => e\n",
"153": " STDERR.puts \"Error reached top of thread-pool: #{e.message} (#{e.class})\"\n"
},
"context": "all"
}
],
"application_trace": [
{
"number": "69",
"file": "[PROJECT_ROOT]/app/controllers/application_controller.rb",
"method": "check_redirect",
"source": {
"67": "\n",
"68": " def check_redirect\n",
"69": " return unless (redirect = Redirect.find_by(slug: request.path.sub(%r{^/}, \"\")))\n",
"70": " redirect_to redirect.url\n",
"71": " end\n"
},
"application_file": "app/controllers/application_controller.rb",
"context": "app"
}
],
"web_environment": {
"SERVER_SOFTWARE": "puma 6.3.1 Mugi No Toki Itaru",
"GATEWAY_INTERFACE": "CGI/1.2",
"REQUEST_METHOD": "GET",
"SERVER_PROTOCOL": "HTTP/1.1",
"HTTP_HOST": "example.com",
"HTTP_CONNECTION": "close",
"HTTP_USER_AGENT": "Amazon CloudFront",
"HTTP_X_AMZ_CF_ID": "yai2eezeewaipahthieN-Yt3y0gAunRuwBHH8A==",
"HTTP_IF_NONE_MATCH": "W/\"fde6ca645252fa81edfdae38dbeef178\"",
"HTTP_ACCEPT": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
"HTTP_X_FORWARDED_FOR": "199.175.219.155, 64.252.73.106",
"HTTP_VIA": "2.0 yai2eezeewaipahthieN.cloudfront.net (CloudFront), 1.1 vegur",
"HTTP_ACCEPT_ENCODING": "gzip",
"HTTP_IF_MODIFIED_SINCE": "Wed, 11 Oct 2023 20:51:58 GMT",
"HTTP_SEC_CH_UA": "\"Google Chrome\";v=\"117\", \"Not;A=Brand\";v=\"8\", \"Chromium\";v=\"117\"",
"HTTP_SEC_CH_UA_MOBILE": "?0",
"HTTP_SEC_CH_UA_PLATFORM": "\"Windows\"",
"HTTP_UPGRADE_INSECURE_REQUESTS": "1",
"HTTP_SEC_PURPOSE": "prefetch;prerender",
"HTTP_PURPOSE": "prefetch",
"HTTP_SEC_FETCH_SITE": "none",
"HTTP_SEC_FETCH_MODE": "navigate",
"HTTP_SEC_FETCH_USER": "?1",
"HTTP_SEC_FETCH_DEST": "document",
"HTTP_X_REQUEST_ID": "fb536bf3-76d0-4936-a354-2a3d023b2cf4",
"HTTP_X_FORWARDED_PROTO": "https",
"HTTP_X_FORWARDED_PORT": "443",
"HTTP_CONNECT_TIME": "1",
"HTTP_X_REQUEST_START": "1697220489932",
"HTTP_TOTAL_ROUTE_TIME": "0",
"SERVER_NAME": "example.com",
"SERVER_PORT": "443",
"REMOTE_ADDR": "10.1.5.53",
"HTTP_VERSION": "HTTP/1.1"
},
"deploy": {
"environment": "production",
"revision": "0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "ben@example.com",
"created_at": "2023-10-06T20:52:51.878336Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/d4f90c876adf4a108ebb9a6f47b5562b59578d97...0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba"
},
"url": "https://app.honeybadger.io/projects/123321/faults/101337516/01HCN3JWWXRQX511BB83WM2X95"
}
}
```
# Rate exceeded event payload
> Sent when error rate threshold is exceeded.
Sent when error rate threshold is exceeded.
```json
{
"event": "rate_exceeded",
"message": "[Testy McTestFace/production] ActiveRecord::NoDatabaseError has occurred time(s) in the past ",
"project": {
"id": 123321,
"name": "Testy McTestFace",
"created_at": "2017-08-30T12:54:33.156695Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "zzz111",
"github_project": "spacely/testy-mctestface",
"environments": [
{
"id": 68210,
"project_id": 123321,
"name": "production",
"notifications": true,
"created_at": "2017-09-05T06:10:19.057794Z",
"updated_at": "2017-09-05T06:10:19.057794Z"
},
{
"id": 68074,
"project_id": 123321,
"name": "development",
"notifications": true,
"created_at": "2017-08-30T12:55:29.297392Z",
"updated_at": "2017-08-30T12:55:29.297392Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2023-10-30T19:29:08.000000Z",
"earliest_notice_at": "2023-05-03T19:37:25.519130Z",
"unresolved_fault_count": 102,
"fault_count": 925,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
},
{
"id": 99,
"email": "george@example.com",
"name": "George Jetson"
}
],
"sites": [
{
"id": "c42c4c0a-6e3d-4303-9769-549ed2a5818e",
"active": true,
"last_checked_at": "2023-10-30T19:34:08.150725Z",
"name": "Heroku",
"state": "up",
"url": "https://example.com"
}
],
"team_id": 1
},
"fault": {
"project_id": 123321,
"klass": "ActiveRecord::NoDatabaseError",
"component": "pages",
"action": "home",
"environment": "production",
"resolved": false,
"ignored": false,
"created_at": "2023-10-13T18:07:55.692256Z",
"comments_count": 0,
"message": "We could not find your database: d6ipl26lboesdi. Which can be found in the database configuration file located at config/database.yml.\n\nTo resolve this issue:\n\n- Did you create the database for this app, or delete it? You may need to create your database.\n- Has the database name changed? Check your database.yml config has the correct database name.\n\nTo create your database, run:\n\n bin/rails db:create",
"notices_count": 6,
"last_notice_at": "2023-10-13T18:08:10.000000Z",
"tags": [],
"id": 101337516,
"assignee": null,
"url": "https://app.honeybadger.io/projects/123321/faults/101337516",
"deploy": {
"environment": "production",
"revision": "0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "ben@example.com",
"created_at": "2023-10-06T20:52:51.878336Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/d4f90c876adf4a108ebb9a6f47b5562b59578d97...0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba"
}
},
"notice": {
"id": 1013375161697220500,
"environment": {},
"created_at": "2023-10-13T18:08:10.141219Z",
"message": null,
"token": "babe1d9d-67e3-4438-8c57-c544cea24ffb",
"fault_id": 101337516,
"request": {
"url": "https://example.com/",
"component": "pages",
"action": "home",
"params": {
"controller": "pages",
"action": "home"
},
"session": {},
"context": {}
},
"backtrace": [
{
"number": "81",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/postgresql_adapter.rb",
"method": "rescue in new_client",
"source": {
"79": " rescue ::PG::Error => error\n",
"80": " if conn_params && conn_params[:dbname] && error.message.include?(conn_params[:dbname])\n",
"81": " raise ActiveRecord::NoDatabaseError.db_error(conn_params[:dbname])\n",
"82": " elsif conn_params && conn_params[:user] && error.message.include?(conn_params[:user])\n",
"83": " raise ActiveRecord::DatabaseConnectionError.username_error(conn_params[:user])\n"
},
"context": "all"
},
{
"number": "77",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/postgresql_adapter.rb",
"method": "new_client",
"source": {
"75": "\n",
"76": " class << self\n",
"77": " def new_client(conn_params)\n",
"78": " PG.connect(**conn_params)\n",
"79": " rescue ::PG::Error => error\n"
},
"context": "all"
},
{
"number": "37",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/postgresql_adapter.rb",
"method": "postgresql_connection",
"source": {
"35": "\n",
"36": " ConnectionAdapters::PostgreSQLAdapter.new(\n",
"37": " ConnectionAdapters::PostgreSQLAdapter.new_client(conn_params),\n",
"38": " logger,\n",
"39": " conn_params,\n"
},
"context": "all"
},
{
"number": "656",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "public_send",
"source": {
"654": "\n",
"655": " def new_connection\n",
"656": " Base.public_send(db_config.adapter_method, db_config.configuration_hash).tap do |conn|\n",
"657": " conn.check_version\n",
"658": " end\n"
},
"context": "all"
},
{
"number": "656",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "new_connection",
"source": {
"654": "\n",
"655": " def new_connection\n",
"656": " Base.public_send(db_config.adapter_method, db_config.configuration_hash).tap do |conn|\n",
"657": " conn.check_version\n",
"658": " end\n"
},
"context": "all"
},
{
"number": "700",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "checkout_new_connection",
"source": {
"698": " def checkout_new_connection\n",
"699": " raise ConnectionNotEstablished unless @automatic_reconnect\n",
"700": " new_connection\n",
"701": " end\n",
"702": "\n"
},
"context": "all"
},
{
"number": "679",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "try_to_checkout_new_connection",
"source": {
"677": " # if successfully incremented @now_connecting establish new connection\n",
"678": " # outside of synchronized section\n",
"679": " conn = checkout_new_connection\n",
"680": " ensure\n",
"681": " synchronize do\n"
},
"context": "all"
},
{
"number": "640",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "acquire_connection",
"source": {
"638": " # and +try_to_checkout_new_connection+ we can piggyback on +synchronize+ sections\n",
"639": " # of the said methods and avoid an additional +synchronize+ overhead.\n",
"640": " if conn = @available.poll || try_to_checkout_new_connection\n",
"641": " conn\n",
"642": " else\n"
},
"context": "all"
},
{
"number": "341",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "checkout",
"source": {
"339": " # - ActiveRecord::ConnectionTimeoutError no connection can be obtained from the pool.\n",
"340": " def checkout(checkout_timeout = @checkout_timeout)\n",
"341": " checkout_and_verify(acquire_connection(checkout_timeout))\n",
"342": " end\n",
"343": "\n"
},
"context": "all"
},
{
"number": "181",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_pool.rb",
"method": "connection",
"source": {
"179": " # held in a cache keyed by a thread.\n",
"180": " def connection\n",
"181": " @thread_cached_conns[connection_cache_key(current_thread)] ||= checkout\n",
"182": " end\n",
"183": "\n"
},
"context": "all"
},
{
"number": "211",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_adapters/abstract/connection_handler.rb",
"method": "retrieve_connection",
"source": {
"209": " end\n",
"210": "\n",
"211": " pool.connection\n",
"212": " end\n",
"213": "\n"
},
"context": "all"
},
{
"number": "313",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_handling.rb",
"method": "retrieve_connection",
"source": {
"311": "\n",
"312": " def retrieve_connection\n",
"313": " connection_handler.retrieve_connection(connection_specification_name, role: current_role, shard: current_shard)\n",
"314": " end\n",
"315": "\n"
},
"context": "all"
},
{
"number": "280",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/connection_handling.rb",
"method": "connection",
"source": {
"278": " # to any of the specific Active Records.\n",
"279": " def connection\n",
"280": " retrieve_connection\n",
"281": " end\n",
"282": "\n"
},
"context": "all"
},
{
"number": "433",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/core.rb",
"method": "cached_find_by_statement",
"source": {
"431": "\n",
"432": " def cached_find_by_statement(key, &block) # :nodoc:\n",
"433": " cache = @find_by_statement_cache[connection.prepared_statements]\n",
"434": " cache.compute_if_absent(key) { StatementCache.create(connection, &block) }\n",
"435": " end\n"
},
"context": "all"
},
{
"number": "317",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/core.rb",
"method": "find_by",
"source": {
"315": "\n",
"316": " keys = hash.keys\n",
"317": " statement = cached_find_by_statement(keys) { |params|\n",
"318": " wheres = keys.index_with { params.bind }\n",
"319": " where(wheres).limit(1)\n"
},
"context": "all"
},
{
"number": "69",
"file": "[PROJECT_ROOT]/app/controllers/application_controller.rb",
"method": "check_redirect",
"source": {
"67": "\n",
"68": " def check_redirect\n",
"69": " return unless (redirect = Redirect.find_by(slug: request.path.sub(%r{^/}, \"\")))\n",
"70": " redirect_to redirect.url\n",
"71": " end\n"
},
"application_file": "app/controllers/application_controller.rb",
"context": "app"
},
{
"number": "400",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block in make_lambda",
"source": {
"398": " def make_lambda\n",
"399": " lambda do |target, value, &block|\n",
"400": " target.send(@method_name, &block)\n",
"401": " end\n",
"402": " end\n"
},
"context": "all"
},
{
"number": "180",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block (2 levels) in halting_and_conditional",
"source": {
"178": "\n",
"179": " if !halted && user_conditions.all? { |c| c.call(target, value) }\n",
"180": " result_lambda = -> { user_callback.call target, value }\n",
"181": " env.halted = halted_lambda.call(target, result_lambda)\n",
"182": " if env.halted\n"
},
"context": "all"
},
{
"number": "34",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/abstract_controller/callbacks.rb",
"method": "block (2 levels) in ",
"source": {
"32": " included do\n",
"33": " define_callbacks :process_action,\n",
"34": " terminator: ->(controller, result_lambda) { result_lambda.call; controller.performed? },\n",
"35": " skip_after_callbacks_if_terminated: true\n",
"36": " end\n"
},
"context": "all"
},
{
"number": "181",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block in halting_and_conditional",
"source": {
"179": " if !halted && user_conditions.all? { |c| c.call(target, value) }\n",
"180": " result_lambda = -> { user_callback.call target, value }\n",
"181": " env.halted = halted_lambda.call(target, result_lambda)\n",
"182": " if env.halted\n",
"183": " target.send :halted_callback_hook, filter, name\n"
},
"context": "all"
},
{
"number": "595",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "block in invoke_before",
"source": {
"593": "\n",
"594": " def invoke_before(arg)\n",
"595": " @before.each { |b| b.call(arg) }\n",
"596": " end\n",
"597": "\n"
},
"context": "all"
},
{
"number": "595",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "each",
"source": {
"593": "\n",
"594": " def invoke_before(arg)\n",
"595": " @before.each { |b| b.call(arg) }\n",
"596": " end\n",
"597": "\n"
},
"context": "all"
},
{
"number": "595",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "invoke_before",
"source": {
"593": "\n",
"594": " def invoke_before(arg)\n",
"595": " @before.each { |b| b.call(arg) }\n",
"596": " end\n",
"597": "\n"
},
"context": "all"
},
{
"number": "106",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "run_callbacks",
"source": {
"104": " # Common case: no 'around' callbacks defined\n",
"105": " if next_sequence.final?\n",
"106": " next_sequence.invoke_before(env)\n",
"107": " env.value = !env.halted && (!block_given? || yield)\n",
"108": " next_sequence.invoke_after(env)\n"
},
"context": "all"
},
{
"number": "233",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/abstract_controller/callbacks.rb",
"method": "process_action",
"source": {
"231": " # process_action callbacks around the normal behavior.\n",
"232": " def process_action(...)\n",
"233": " run_callbacks(:process_action) do\n",
"234": " super\n",
"235": " end\n"
},
"context": "all"
},
{
"number": "23",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/rescue.rb",
"method": "process_action",
"source": {
"21": " private\n",
"22": " def process_action(*)\n",
"23": " super\n",
"24": " rescue Exception => exception\n",
"25": " request.env[\"action_dispatch.show_detailed_exceptions\"] ||= show_detailed_exceptions?\n"
},
"context": "all"
},
{
"number": "67",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/instrumentation.rb",
"method": "block in process_action",
"source": {
"65": "\n",
"66": " ActiveSupport::Notifications.instrument(\"process_action.action_controller\", raw_payload) do |payload|\n",
"67": " result = super\n",
"68": " payload[:response] = response\n",
"69": " payload[:status] = response.status\n"
},
"context": "all"
},
{
"number": "206",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/notifications.rb",
"method": "block in instrument",
"source": {
"204": " def instrument(name, payload = {})\n",
"205": " if notifier.listening?(name)\n",
"206": " instrumenter.instrument(name, payload) { yield payload if block_given? }\n",
"207": " else\n",
"208": " yield payload if block_given?\n"
},
"context": "all"
},
{
"number": "24",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/notifications/instrumenter.rb",
"method": "instrument",
"source": {
"22": " listeners_state = start name, payload\n",
"23": " begin\n",
"24": " yield payload if block_given?\n",
"25": " rescue Exception => e\n",
"26": " payload[:exception] = [e.class.name, e.message]\n"
},
"context": "all"
},
{
"number": "206",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/notifications.rb",
"method": "instrument",
"source": {
"204": " def instrument(name, payload = {})\n",
"205": " if notifier.listening?(name)\n",
"206": " instrumenter.instrument(name, payload) { yield payload if block_given? }\n",
"207": " else\n",
"208": " yield payload if block_given?\n"
},
"context": "all"
},
{
"number": "66",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/instrumentation.rb",
"method": "process_action",
"source": {
"64": " ActiveSupport::Notifications.instrument(\"start_processing.action_controller\", raw_payload)\n",
"65": "\n",
"66": " ActiveSupport::Notifications.instrument(\"process_action.action_controller\", raw_payload) do |payload|\n",
"67": " result = super\n",
"68": " payload[:response] = response\n"
},
"context": "all"
},
{
"number": "259",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal/params_wrapper.rb",
"method": "process_action",
"source": {
"257": " def process_action(*)\n",
"258": " _perform_parameter_wrapping if _wrapper_enabled?\n",
"259": " super\n",
"260": " end\n",
"261": "\n"
},
"context": "all"
},
{
"number": "27",
"file": "[GEM_ROOT]/gems/activerecord-7.0.7.2/lib/active_record/railties/controller_runtime.rb",
"method": "process_action",
"source": {
"25": " # and it won't be cleaned up by the method below.\n",
"26": " ActiveRecord::LogSubscriber.reset_runtime\n",
"27": " super\n",
"28": " end\n",
"29": "\n"
},
"context": "all"
},
{
"number": "120",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/instruments/action_controller_rails_3_rails4.rb",
"method": "process_action",
"source": {
"118": " req.start_layer( ScoutApm::Layer.new(\"Controller\", \"#{controller_path}/#{resolved_name}\") )\n",
"119": " begin\n",
"120": " super\n",
"121": " rescue\n",
"122": " req.error!\n"
},
"context": "all"
},
{
"number": "151",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/abstract_controller/base.rb",
"method": "process",
"source": {
"149": " @_response_body = nil\n",
"150": "\n",
"151": " process_action(action_name, *args)\n",
"152": " end\n",
"153": " ruby2_keywords(:process)\n"
},
"context": "all"
},
{
"number": "39",
"file": "[GEM_ROOT]/gems/actionview-7.0.7.2/lib/action_view/rendering.rb",
"method": "process",
"source": {
"37": " def process(...) # :nodoc:\n",
"38": " old_config, I18n.config = I18n.config, I18nProxy.new(I18n.config, lookup_context)\n",
"39": " super\n",
"40": " ensure\n",
"41": " I18n.config = old_config\n"
},
"context": "all"
},
{
"number": "188",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal.rb",
"method": "dispatch",
"source": {
"186": " set_request!(request)\n",
"187": " set_response!(response)\n",
"188": " process(name)\n",
"189": " request.commit_flash\n",
"190": " to_a\n"
},
"context": "all"
},
{
"number": "251",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_controller/metal.rb",
"method": "dispatch",
"source": {
"249": " middleware_stack.build(name) { |env| new.dispatch(name, req, res) }.call req.env\n",
"250": " else\n",
"251": " new.dispatch(name, req, res)\n",
"252": " end\n",
"253": " end\n"
},
"context": "all"
},
{
"number": "49",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/routing/route_set.rb",
"method": "dispatch",
"source": {
"47": "\n",
"48": " def dispatch(controller, action, req, res)\n",
"49": " controller.dispatch(action, req, res)\n",
"50": " end\n",
"51": " end\n"
},
"context": "all"
},
{
"number": "32",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/routing/route_set.rb",
"method": "serve",
"source": {
"30": " controller = controller req\n",
"31": " res = controller.make_response! req\n",
"32": " dispatch(controller, params[:action], req, res)\n",
"33": " rescue ActionController::RoutingError\n",
"34": " if @raise_on_name_error\n"
},
"context": "all"
},
{
"number": "50",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/journey/router.rb",
"method": "block in serve",
"source": {
"48": " req.path_parameters = tmp_params\n",
"49": "\n",
"50": " status, headers, body = route.app.serve(req)\n",
"51": "\n",
"52": " if \"pass\" == headers[\"X-Cascade\"]\n"
},
"context": "all"
},
{
"number": "32",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/journey/router.rb",
"method": "each",
"source": {
"30": "\n",
"31": " def serve(req)\n",
"32": " find_routes(req).each do |match, parameters, route|\n",
"33": " set_params = req.path_parameters\n",
"34": " path_info = req.path_info\n"
},
"context": "all"
},
{
"number": "32",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/journey/router.rb",
"method": "serve",
"source": {
"30": "\n",
"31": " def serve(req)\n",
"32": " find_routes(req).each do |match, parameters, route|\n",
"33": " set_params = req.path_parameters\n",
"34": " path_info = req.path_info\n"
},
"context": "all"
},
{
"number": "852",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/routing/route_set.rb",
"method": "call",
"source": {
"850": " req = make_request(env)\n",
"851": " req.path_info = Journey::Router::Utils.normalize_path(req.path_info)\n",
"852": " @router.serve(req)\n",
"853": " end\n",
"854": "\n"
},
"context": "all"
},
{
"number": "29",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/instruments/rails_router.rb",
"method": "call_with_scout_instruments",
"source": {
"27": "\n",
"28": " begin\n",
"29": " call_without_scout_instruments(*args)\n",
"30": " ensure\n",
"31": " req.stop_layer\n"
},
"context": "all"
},
{
"number": "17",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/middleware.rb",
"method": "call",
"source": {
"15": " def call(env)\n",
"16": " if !@enabled || @started || @attempts > MAX_ATTEMPTS\n",
"17": " @app.call(env)\n",
"18": " else\n",
"19": " attempt_to_start_agent\n"
},
"context": "all"
},
{
"number": "36",
"file": "[GEM_ROOT]/gems/warden-1.2.9/lib/warden/manager.rb",
"method": "block in call",
"source": {
"34": " result = catch(:warden) do\n",
"35": " env['warden'].on_request\n",
"36": " @app.call(env)\n",
"37": " end\n",
"38": "\n"
},
"context": "all"
},
{
"number": "34",
"file": "[GEM_ROOT]/gems/warden-1.2.9/lib/warden/manager.rb",
"method": "catch",
"source": {
"32": "\n",
"33": " env['warden'] = Proxy.new(env, self)\n",
"34": " result = catch(:warden) do\n",
"35": " env['warden'].on_request\n",
"36": " @app.call(env)\n"
},
"context": "all"
},
{
"number": "34",
"file": "[GEM_ROOT]/gems/warden-1.2.9/lib/warden/manager.rb",
"method": "call",
"source": {
"32": "\n",
"33": " env['warden'] = Proxy.new(env, self)\n",
"34": " result = catch(:warden) do\n",
"35": " env['warden'].on_request\n",
"36": " @app.call(env)\n"
},
"context": "all"
},
{
"number": "15",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/tempfile_reaper.rb",
"method": "call",
"source": {
"13": " def call(env)\n",
"14": " env[RACK_TEMPFILES] ||= []\n",
"15": " status, headers, body = @app.call(env)\n",
"16": " body_proxy = BodyProxy.new(body) do\n",
"17": " env[RACK_TEMPFILES].each(&:close!) unless env[RACK_TEMPFILES].nil?\n"
},
"context": "all"
},
{
"number": "27",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/conditional_get.rb",
"method": "call",
"source": {
"25": " case env[REQUEST_METHOD]\n",
"26": " when \"GET\", \"HEAD\"\n",
"27": " status, headers, body = @app.call(env)\n",
"28": " headers = Utils::HeaderHash[headers]\n",
"29": " if status == 200 && fresh?(env, headers)\n"
},
"context": "all"
},
{
"number": "12",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/head.rb",
"method": "call",
"source": {
"10": "\n",
"11": " def call(env)\n",
"12": " status, headers, body = @app.call(env)\n",
"13": "\n",
"14": " if env[REQUEST_METHOD] == HEAD\n"
},
"context": "all"
},
{
"number": "38",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/http/permissions_policy.rb",
"method": "call",
"source": {
"36": " def call(env)\n",
"37": " request = ActionDispatch::Request.new(env)\n",
"38": " _, headers, _ = response = @app.call(env)\n",
"39": "\n",
"40": " return response unless html_response?(headers)\n"
},
"context": "all"
},
{
"number": "36",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/http/content_security_policy.rb",
"method": "call",
"source": {
"34": " def call(env)\n",
"35": " request = ActionDispatch::Request.new env\n",
"36": " status, headers, _ = response = @app.call(env)\n",
"37": "\n",
"38": " # Returning CSP headers with a 304 Not Modified is harmful, since nonces in the new\n"
},
"context": "all"
},
{
"number": "266",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/session/abstract/id.rb",
"method": "context",
"source": {
"264": " req = make_request env\n",
"265": " prepare_session(req)\n",
"266": " status, headers, body = app.call(req.env)\n",
"267": " res = Rack::Response::Raw.new status, headers\n",
"268": " commit_session(req, res)\n"
},
"context": "all"
},
{
"number": "260",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/session/abstract/id.rb",
"method": "call",
"source": {
"258": "\n",
"259": " def call(env)\n",
"260": " context(env)\n",
"261": " end\n",
"262": "\n"
},
"context": "all"
},
{
"number": "704",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/cookies.rb",
"method": "call",
"source": {
"702": " request = ActionDispatch::Request.new env\n",
"703": "\n",
"704": " status, headers, body = @app.call(env)\n",
"705": "\n",
"706": " if request.have_cookie_jar?\n"
},
"context": "all"
},
{
"number": "27",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/callbacks.rb",
"method": "block in call",
"source": {
"25": " error = nil\n",
"26": " result = run_callbacks :call do\n",
"27": " @app.call(env)\n",
"28": " rescue => error\n",
"29": " end\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/callbacks.rb",
"method": "run_callbacks",
"source": {
"97": "\n",
"98": " if callbacks.empty?\n",
"99": " yield if block_given?\n",
"100": " else\n",
"101": " env = Filters::Environment.new(self, false, nil)\n"
},
"context": "all"
},
{
"number": "26",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/callbacks.rb",
"method": "call",
"source": {
"24": " def call(env)\n",
"25": " error = nil\n",
"26": " result = run_callbacks :call do\n",
"27": " @app.call(env)\n",
"28": " rescue => error\n"
},
"context": "all"
},
{
"number": "28",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/debug_exceptions.rb",
"method": "call",
"source": {
"26": " def call(env)\n",
"27": " request = ActionDispatch::Request.new env\n",
"28": " _, headers, body = response = @app.call(env)\n",
"29": "\n",
"30": " if headers[\"X-Cascade\"] == \"pass\"\n"
},
"context": "all"
},
{
"number": "29",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/show_exceptions.rb",
"method": "call",
"source": {
"27": " def call(env)\n",
"28": " request = ActionDispatch::Request.new env\n",
"29": " @app.call(env)\n",
"30": " rescue Exception => exception\n",
"31": " if request.show_exceptions?\n"
},
"context": "all"
},
{
"number": "18",
"file": "[GEM_ROOT]/gems/lograge-0.12.0/lib/lograge/rails_ext/rack/logger.rb",
"method": "call_app",
"source": {
"16": " def call_app(*args)\n",
"17": " env = args.last\n",
"18": " status, headers, body = @app.call(env)\n",
"19": " # needs to have same return type as the Rails builtins being overridden, see https://github.com/roidrage/lograge/pull/333\n",
"20": " # https://github.com/rails/rails/blob/be9d34b9bcb448b265114ebc28bef1a5b5e4c272/railties/lib/rails/rack/logger.rb#L37\n"
},
"context": "all"
},
{
"number": "25",
"file": "[GEM_ROOT]/gems/railties-7.0.7.2/lib/rails/rack/logger.rb",
"method": "block in call",
"source": {
"23": "\n",
"24": " if logger.respond_to?(:tagged)\n",
"25": " logger.tagged(compute_tags(request)) { call_app(request, env) }\n",
"26": " else\n",
"27": " call_app(request, env)\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/tagged_logging.rb",
"method": "block in tagged",
"source": {
"97": " def tagged(*tags)\n",
"98": " if block_given?\n",
"99": " formatter.tagged(*tags) { yield self }\n",
"100": " else\n",
"101": " logger = ActiveSupport::TaggedLogging.new(self)\n"
},
"context": "all"
},
{
"number": "37",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/tagged_logging.rb",
"method": "tagged",
"source": {
"35": " def tagged(*tags)\n",
"36": " new_tags = push_tags(*tags)\n",
"37": " yield self\n",
"38": " ensure\n",
"39": " pop_tags(new_tags.size)\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/tagged_logging.rb",
"method": "tagged",
"source": {
"97": " def tagged(*tags)\n",
"98": " if block_given?\n",
"99": " formatter.tagged(*tags) { yield self }\n",
"100": " else\n",
"101": " logger = ActiveSupport::TaggedLogging.new(self)\n"
},
"context": "all"
},
{
"number": "25",
"file": "[GEM_ROOT]/gems/railties-7.0.7.2/lib/rails/rack/logger.rb",
"method": "call",
"source": {
"23": "\n",
"24": " if logger.respond_to?(:tagged)\n",
"25": " logger.tagged(compute_tags(request)) { call_app(request, env) }\n",
"26": " else\n",
"27": " call_app(request, env)\n"
},
"context": "all"
},
{
"number": "93",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/remote_ip.rb",
"method": "call",
"source": {
"91": " req = ActionDispatch::Request.new env\n",
"92": " req.remote_ip = GetIp.new(req, check_ip, proxies)\n",
"93": " @app.call(req.env)\n",
"94": " end\n",
"95": "\n"
},
"context": "all"
},
{
"number": "19",
"file": "[GEM_ROOT]/gems/request_store-1.5.1/lib/request_store/middleware.rb",
"method": "call",
"source": {
"17": " RequestStore.begin!\r\n",
"18": "\r\n",
"19": " status, headers, body = @app.call(env)\r\n",
"20": "\r\n",
"21": " body = Rack::BodyProxy.new(body) do\r\n"
},
"context": "all"
},
{
"number": "26",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/request_id.rb",
"method": "call",
"source": {
"24": " req = ActionDispatch::Request.new env\n",
"25": " req.request_id = make_request_id(req.headers[@header])\n",
"26": " @app.call(env).tap { |_status, headers, _body| headers[@header] = req.request_id }\n",
"27": " end\n",
"28": "\n"
},
"context": "all"
},
{
"number": "24",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/method_override.rb",
"method": "call",
"source": {
"22": " end\n",
"23": "\n",
"24": " @app.call(env)\n",
"25": " end\n",
"26": "\n"
},
"context": "all"
},
{
"number": "22",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/runtime.rb",
"method": "call",
"source": {
"20": " def call(env)\n",
"21": " start_time = Utils.clock_time\n",
"22": " status, headers, body = @app.call(env)\n",
"23": " headers = Utils::HeaderHash[headers]\n",
"24": "\n"
},
"context": "all"
},
{
"number": "148",
"file": "[GEM_ROOT]/gems/rack-timeout-0.6.3/lib/rack/timeout/core.rb",
"method": "block in call",
"source": {
"146": "\n",
"147": " response = timeout.timeout(info.timeout) do # perform request with timeout\n",
"148": " begin @app.call(env) # boom, send request down the middleware chain\n",
"149": " rescue RequestTimeoutException => e # will actually hardly ever get to this point because frameworks tend to catch this. see README for more\n",
"150": " raise RequestTimeoutError.new(env), e.message, e.backtrace # but in case it does get here, re-raise RequestTimeoutException as RequestTimeoutError\n"
},
"context": "all"
},
{
"number": "19",
"file": "[GEM_ROOT]/gems/rack-timeout-0.6.3/lib/rack/timeout/support/timeout.rb",
"method": "timeout",
"source": {
"17": " thr = Thread.current # reference to current thread to be used in timeout thread\n",
"18": " job = @scheduler.run_in(secs) { @on_timeout.call thr } # schedule this thread to be timed out; should get cancelled if block completes on time\n",
"19": " return block.call # do what you gotta do\n",
"20": " ensure #\n",
"21": " job.cancel! if job # cancel the scheduled timeout job; if the block completed on time, this\n"
},
"context": "all"
},
{
"number": "147",
"file": "[GEM_ROOT]/gems/rack-timeout-0.6.3/lib/rack/timeout/core.rb",
"method": "call",
"source": {
"145": " end\n",
"146": "\n",
"147": " response = timeout.timeout(info.timeout) do # perform request with timeout\n",
"148": " begin @app.call(env) # boom, send request down the middleware chain\n",
"149": " rescue RequestTimeoutException => e # will actually hardly ever get to this point because frameworks tend to catch this. see README for more\n"
},
"context": "all"
},
{
"number": "41",
"file": "[GEM_ROOT]/gems/judoscale-ruby-1.4.1/lib/judoscale/request_middleware.rb",
"method": "call",
"source": {
"39": " end\n",
"40": "\n",
"41": " @app.call(env)\n",
"42": " end\n",
"43": " end\n"
},
"context": "all"
},
{
"number": "29",
"file": "[GEM_ROOT]/gems/activesupport-7.0.7.2/lib/active_support/cache/strategy/local_cache_middleware.rb",
"method": "call",
"source": {
"27": " def call(env)\n",
"28": " LocalCacheRegistry.set_cache_for(local_cache_key, LocalStore.new)\n",
"29": " response = @app.call(env)\n",
"30": " response[2] = ::Rack::BodyProxy.new(response[2]) do\n",
"31": " LocalCacheRegistry.set_cache_for(local_cache_key, nil)\n"
},
"context": "all"
},
{
"number": "24",
"file": "[GEM_ROOT]/gems/rack-rewrite-1.5.1/lib/rack/rewrite.rb",
"method": "call",
"source": {
"22": " return rack_response unless rack_response === true\n",
"23": " end\n",
"24": " @app.call(env)\n",
"25": " end\n",
"26": " \n"
},
"context": "all"
},
{
"number": "14",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/executor.rb",
"method": "call",
"source": {
"12": " state = @executor.run!(reset: true)\n",
"13": " begin\n",
"14": " response = @app.call(env)\n",
"15": " returned = response << ::Rack::BodyProxy.new(response.pop) { state.complete! }\n",
"16": " rescue => error\n"
},
"context": "all"
},
{
"number": "23",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/static.rb",
"method": "call",
"source": {
"21": "\n",
"22": " def call(env)\n",
"23": " @file_handler.attempt(env) || @app.call(env)\n",
"24": " end\n",
"25": " end\n"
},
"context": "all"
},
{
"number": "110",
"file": "[GEM_ROOT]/gems/rack-2.2.8/lib/rack/sendfile.rb",
"method": "call",
"source": {
"108": "\n",
"109": " def call(env)\n",
"110": " status, headers, body = @app.call(env)\n",
"111": " if body.respond_to?(:to_path)\n",
"112": " case type = variation(env)\n"
},
"context": "all"
},
{
"number": "77",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/ssl.rb",
"method": "call",
"source": {
"75": "\n",
"76": " if request.ssl?\n",
"77": " @app.call(env).tap do |status, headers, body|\n",
"78": " set_hsts_header! headers\n",
"79": " flag_cookies_as_secure! headers if @secure_cookies && !@exclude.call(request)\n"
},
"context": "all"
},
{
"number": "131",
"file": "[GEM_ROOT]/gems/actionpack-7.0.7.2/lib/action_dispatch/middleware/host_authorization.rb",
"method": "call",
"source": {
"129": "\n",
"130": " def call(env)\n",
"131": " return @app.call(env) if @permissions.empty?\n",
"132": "\n",
"133": " request = Request.new(env)\n"
},
"context": "all"
},
{
"number": "58",
"file": "[GEM_ROOT]/gems/scout_apm-5.3.5/lib/scout_apm/instruments/middleware_summary.rb",
"method": "call",
"source": {
"56": " layer = ScoutApm::Layer.new(\"Middleware\", \"Summary\")\n",
"57": " req.start_layer(layer)\n",
"58": " @app.call(env)\n",
"59": " ensure\n",
"60": " req.stop_layer\n"
},
"context": "all"
},
{
"number": "530",
"file": "[GEM_ROOT]/gems/railties-7.0.7.2/lib/rails/engine.rb",
"method": "call",
"source": {
"528": " def call(env)\n",
"529": " req = build_request env\n",
"530": " app.call req.env\n",
"531": " end\n",
"532": "\n"
},
"context": "all"
},
{
"number": "270",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/configuration.rb",
"method": "call",
"source": {
"268": " def call(env)\n",
"269": " env[Const::PUMA_CONFIG] = @config\n",
"270": " @app.call(env)\n",
"271": " end\n",
"272": " end\n"
},
"context": "all"
},
{
"number": "100",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/request.rb",
"method": "block in handle_request",
"source": {
"98": " if @supported_http_methods == :any || @supported_http_methods.key?(env[REQUEST_METHOD])\n",
"99": " status, headers, app_body = @thread_pool.with_force_shutdown do\n",
"100": " @app.call(env)\n",
"101": " end\n",
"102": " else\n"
},
"context": "all"
},
{
"number": "344",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/thread_pool.rb",
"method": "with_force_shutdown",
"source": {
"342": " t[:with_force_shutdown] = true\n",
"343": " end\n",
"344": " yield\n",
"345": " ensure\n",
"346": " t[:with_force_shutdown] = false\n"
},
"context": "all"
},
{
"number": "99",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/request.rb",
"method": "handle_request",
"source": {
"97": " begin\n",
"98": " if @supported_http_methods == :any || @supported_http_methods.key?(env[REQUEST_METHOD])\n",
"99": " status, headers, app_body = @thread_pool.with_force_shutdown do\n",
"100": " @app.call(env)\n",
"101": " end\n"
},
"context": "all"
},
{
"number": "443",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/server.rb",
"method": "process_client",
"source": {
"441": " while true\n",
"442": " @requests_count += 1\n",
"443": " case handle_request(client, requests + 1)\n",
"444": " when false\n",
"445": " break\n"
},
"context": "all"
},
{
"number": "245",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/server.rb",
"method": "block in run",
"source": {
"243": " @status = :run\n",
"244": "\n",
"245": " @thread_pool = ThreadPool.new(thread_name, @options) { |client| process_client client }\n",
"246": "\n",
"247": " if @queue_requests\n"
},
"context": "all"
},
{
"number": "151",
"file": "[GEM_ROOT]/gems/puma-6.3.1/lib/puma/thread_pool.rb",
"method": "block in spawn_thread",
"source": {
"149": "\n",
"150": " begin\n",
"151": " @out_of_band_pending = true if block.call(work)\n",
"152": " rescue Exception => e\n",
"153": " STDERR.puts \"Error reached top of thread-pool: #{e.message} (#{e.class})\"\n"
},
"context": "all"
}
],
"application_trace": [
{
"number": "69",
"file": "[PROJECT_ROOT]/app/controllers/application_controller.rb",
"method": "check_redirect",
"source": {
"67": "\n",
"68": " def check_redirect\n",
"69": " return unless (redirect = Redirect.find_by(slug: request.path.sub(%r{^/}, \"\")))\n",
"70": " redirect_to redirect.url\n",
"71": " end\n"
},
"application_file": "app/controllers/application_controller.rb",
"context": "app"
}
],
"web_environment": {
"SERVER_SOFTWARE": "puma 6.3.1 Mugi No Toki Itaru",
"GATEWAY_INTERFACE": "CGI/1.2",
"REQUEST_METHOD": "GET",
"SERVER_PROTOCOL": "HTTP/1.1",
"HTTP_HOST": "example.com",
"HTTP_CONNECTION": "close",
"HTTP_USER_AGENT": "Amazon CloudFront",
"HTTP_X_AMZ_CF_ID": "yai2eezeewaipahthieN-Yt3y0gAunRuwBHH8A==",
"HTTP_IF_NONE_MATCH": "W/\"fde6ca645252fa81edfdae38dbeef178\"",
"HTTP_ACCEPT": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
"HTTP_X_FORWARDED_FOR": "199.175.219.155, 64.252.73.106",
"HTTP_VIA": "2.0 yai2eezeewaipahthieN.cloudfront.net (CloudFront), 1.1 vegur",
"HTTP_ACCEPT_ENCODING": "gzip",
"HTTP_IF_MODIFIED_SINCE": "Wed, 11 Oct 2023 20:51:58 GMT",
"HTTP_SEC_CH_UA": "\"Google Chrome\";v=\"117\", \"Not;A=Brand\";v=\"8\", \"Chromium\";v=\"117\"",
"HTTP_SEC_CH_UA_MOBILE": "?0",
"HTTP_SEC_CH_UA_PLATFORM": "\"Windows\"",
"HTTP_UPGRADE_INSECURE_REQUESTS": "1",
"HTTP_SEC_PURPOSE": "prefetch;prerender",
"HTTP_PURPOSE": "prefetch",
"HTTP_SEC_FETCH_SITE": "none",
"HTTP_SEC_FETCH_MODE": "navigate",
"HTTP_SEC_FETCH_USER": "?1",
"HTTP_SEC_FETCH_DEST": "document",
"HTTP_X_REQUEST_ID": "fb536bf3-76d0-4936-a354-2a3d023b2cf4",
"HTTP_X_FORWARDED_PROTO": "https",
"HTTP_X_FORWARDED_PORT": "443",
"HTTP_CONNECT_TIME": "1",
"HTTP_X_REQUEST_START": "1697220489932",
"HTTP_TOTAL_ROUTE_TIME": "0",
"SERVER_NAME": "example.com",
"SERVER_PORT": "443",
"REMOTE_ADDR": "10.1.5.53",
"HTTP_VERSION": "HTTP/1.1"
},
"deploy": {
"environment": "production",
"revision": "0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "ben@example.com",
"created_at": "2023-10-06T20:52:51.878336Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/d4f90c876adf4a108ebb9a6f47b5562b59578d97...0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba"
},
"url": "https://app.honeybadger.io/projects/123321/faults/101337516/01HCN3JWWXRQX511BB83WM2X95"
}
}
```
# Error resolved event payload
> Sent when an error is marked as resolved.
Sent when an error is marked as resolved.
```json
{
"event": "resolved",
"message": "[Testy McTestFace/production] ActiveRecord::NoDatabaseError resolved by ",
"fault": {
"project_id": 123321,
"klass": "ActiveRecord::NoDatabaseError",
"component": "pages",
"action": "home",
"environment": "production",
"resolved": false,
"ignored": false,
"created_at": "2023-10-13T18:07:55.692256Z",
"comments_count": 0,
"message": "We could not find your database: d6ipl26lboesdi. Which can be found in the database configuration file located at config/database.yml.\n\nTo resolve this issue:\n\n- Did you create the database for this app, or delete it? You may need to create your database.\n- Has the database name changed? Check your database.yml config has the correct database name.\n\nTo create your database, run:\n\n bin/rails db:create",
"notices_count": 6,
"last_notice_at": "2023-10-13T18:08:10.000000Z",
"tags": [],
"id": 101337516,
"assignee": null,
"url": "https://app.honeybadger.io/projects/123321/faults/101337516",
"deploy": {
"environment": "production",
"revision": "0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "ben@example.com",
"created_at": "2023-10-06T20:52:51.878336Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/d4f90c876adf4a108ebb9a6f47b5562b59578d97...0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba"
}
}
}
```
# Error unresolved event payload
> Sent when a resolved error occurs again.
Sent when a resolved error occurs again.
```json
{
"event": "unresolved",
"message": "[Testy McTestFace/production] ActiveRecord::NoDatabaseError unresolved by ",
"fault": {
"project_id": 123321,
"klass": "ActiveRecord::NoDatabaseError",
"component": "pages",
"action": "home",
"environment": "production",
"resolved": false,
"ignored": false,
"created_at": "2023-10-13T18:07:55.692256Z",
"comments_count": 0,
"message": "We could not find your database: d6ipl26lboesdi. Which can be found in the database configuration file located at config/database.yml.\n\nTo resolve this issue:\n\n- Did you create the database for this app, or delete it? You may need to create your database.\n- Has the database name changed? Check your database.yml config has the correct database name.\n\nTo create your database, run:\n\n bin/rails db:create",
"notices_count": 6,
"last_notice_at": "2023-10-13T18:08:10.000000Z",
"tags": [],
"id": 101337516,
"assignee": null,
"url": "https://app.honeybadger.io/projects/123321/faults/101337516",
"deploy": {
"environment": "production",
"revision": "0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba",
"repository": "https://github.com/spacely/testy-mctestface",
"local_username": "ben@example.com",
"created_at": "2023-10-06T20:52:51.878336Z",
"changelog": [],
"url": "https://github.com/spacely/testy-mctestface/compare/d4f90c876adf4a108ebb9a6f47b5562b59578d97...0eaf61a9ec756be9f4bb511ad71b37baaa9b73ba"
}
}
}
```
# Site up event payload
> Sent when an uptime check succeeds after being down.
Sent when an uptime check succeeds after being down.
```json
{
"event": "up",
"message": "[Testy McTestFace] Heroku is back up after 0m.",
"project": {
"id": 123321,
"name": "Testy McTestFace",
"created_at": "2017-08-30T12:54:33.156695Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "zzz111",
"github_project": "spacely/testy-mctestface",
"environments": [
{
"id": 68210,
"project_id": 123321,
"name": "production",
"notifications": true,
"created_at": "2017-09-05T06:10:19.057794Z",
"updated_at": "2017-09-05T06:10:19.057794Z"
},
{
"id": 68074,
"project_id": 123321,
"name": "development",
"notifications": true,
"created_at": "2017-08-30T12:55:29.297392Z",
"updated_at": "2017-08-30T12:55:29.297392Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2023-10-30T19:29:08.000000Z",
"earliest_notice_at": "2023-05-03T19:38:14.971778Z",
"unresolved_fault_count": 102,
"fault_count": 925,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
},
{
"id": 99,
"email": "george@example.com",
"name": "George Jetson"
}
],
"sites": [
{
"id": "c42c4c0a-6e3d-4303-9769-549ed2a5818e",
"active": true,
"last_checked_at": "2023-10-30T19:34:08.150725Z",
"name": "Heroku",
"state": "up",
"url": "https://example.com"
}
],
"team_id": 1
},
"site": {
"id": "c42c4c0a-6e3d-4303-9769-549ed2a5818e",
"name": "Heroku",
"url": "https://example.com",
"frequency": 5,
"match_type": "success",
"match": null,
"state": "up",
"active": true,
"last_checked_at": "2023-10-30T19:34:08.150725Z",
"retries": 0,
"proxy": 4,
"cert_will_expire_at": null,
"details_url": "https://app.honeybadger.io/projects/123321/sites/c42c4c0a-6e3d-4303-9769-549ed2a5818e"
},
"outage": {
"down_at": "2023-07-17T15:46:52.384701Z",
"up_at": "2023-07-17T15:51:56.063948Z",
"status": null,
"reason": "Connection timed out",
"headers": null,
"details_url": "https://app.honeybadger.io/projects/123321/sites/c42c4c0a-6e3d-4303-9769-549ed2a5818e"
}
}
```
# Volume spike event payload
> Sent when a project's error volume spikes above its learned baseline.
Sent when a project’s total error volume spikes above its learned baseline. See [Error volume anomaly detection](/guides/integrations/#error-volume-anomaly-detection) for details on how spikes are detected.
The subject of this event is the **project** (not an individual error), so the payload has no `fault`. Spike facts are in the `volume_spike` object:
* `observed` — the number of errors in the most recent one-hour window
* `baseline_median` — the project’s typical errors-per-hour (median of the trailing baseline window)
* `factor` — the observed volume as a multiple of the baseline median (e.g. `4.7` means 4.7× the typical rate); `null` when the baseline is near zero
* `z_score` — the modified z-score that triggered the alert
* `window_minutes` — the length of the observed window, in minutes
```json
{
"event": "volume_spike",
"message": "[Testy McTestFace] Errors are 4.7× your normal rate (412 in the last hour vs ~87/hr typical)",
"project": {
"id": 123321,
"name": "Testy McTestFace",
"created_at": "2017-08-30T12:54:33.156695Z",
"disable_public_links": false,
"pivotal_project_id": null,
"asana_workspace_id": null,
"token": "zzz111",
"github_project": "spacely/testy-mctestface",
"environments": [
{
"id": 68210,
"project_id": 123321,
"name": "production",
"notifications": true,
"created_at": "2017-09-05T06:10:19.057794Z",
"updated_at": "2017-09-05T06:10:19.057794Z"
}
],
"owner": {
"id": 1,
"email": "ben@example.com",
"name": "Spacely Sprockets"
},
"last_notice_at": "2023-10-30T19:29:08.000000Z",
"earliest_notice_at": "2023-05-03T19:37:25.519130Z",
"unresolved_fault_count": 102,
"fault_count": 925,
"active": true,
"users": [
{
"id": 1,
"email": "ben@example.com",
"name": "Ben"
}
],
"sites": [],
"team_id": 1
},
"volume_spike": {
"observed": 412,
"baseline_median": 87,
"factor": 4.7,
"z_score": 6.2,
"window_minutes": 60
}
}
```
# Redmine
> Connect Honeybadger to Redmine to automatically create issues from errors and track bug fixes in your project.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Redmine integration
[Section titled “1. Select the Redmine integration”](#1-select-the-redmine-integration)
 
### 2. Set the server & API key
[Section titled “2. Set the server & API key”](#2-set-the-server--api-key)
The server URL is the full URL of your server - including `https://`.
You can find your API key on your account page when logged into Redmine
### 3. Configure transitions (optional)
[Section titled “3. Configure transitions (optional)”](#3-configure-transitions-optional)
You can specify the ids of transitions to be run when issues are resolved and reopened.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Rootly
> Connect Honeybadger to Rootly to automatically trigger incidents from critical errors and application events, and streamline your response workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Create a generic webhook alert source in Rootly.
[Section titled “1. Create a generic webhook alert source in Rootly.”](#1-create-a-generic-webhook-alert-source-in-rootly)
Navigate to the [Alert Sources](https://rootly.com/account/alerts?tab=alert-sources) page in your Rootly account. Locate the **Generic Webhook** alert source and click **Add Source**.
Set the Alert Source Name to “Honeybadger”.
### 2. Locate the authorization header - credentials
[Section titled “2. Locate the authorization header - credentials”](#2-locate-the-authorization-header---credentials)
Rootly will generate a webhook token. Copy this value.
### 3. In Honeybadger, locate the Rootly integration.
[Section titled “3. In Honeybadger, locate the Rootly integration.”](#3-in-honeybadger-locate-the-rootly-integration)
In the project settings, click on the **Integrations** tab where you’ll find the Rootly integration.
### 4. Fill in the required fields and save.
[Section titled “4. Fill in the required fields and save.”](#4-fill-in-the-required-fields-and-save)
Fill in the Webhook authorization token field with the generated token you copied from step 2. You may optionally specify a target type and target ID. Save the integration.
### 5. Test the integration.
[Section titled “5. Test the integration.”](#5-test-the-integration)
Click on the “Test this integration” button to send a test notification to your Rootly account. This will send a test payload to the Rootly webhook alert source.
### 6. Configure the Rootly alert source.
[Section titled “6. Configure the Rootly alert source.”](#6-configure-the-rootly-alert-source)
Now that Rootly has a sample payload, you can easily configure the alert. In your Rootly account, find the configuration settings for the Webhook alert source. Edit the Alert Content and set the following values:
* Alert Title: `{{ alert.data.title }}`
* Alert Description: `{{ alert.data.description }}`
* Link to Alert: `{{ alert.data.url }}`
# Shortcut
> Connect Honeybadger to Shortcut to automatically create stories from errors and track bug fixes in your project workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
 
## Setup
[Section titled “Setup”](#setup)
### 1. Set the organization
[Section titled “1. Set the organization”](#1-set-the-organization)
This is the name of the organization that you created when you set up your account. You can find this immediately after the domain name in the URL: e.g., for the organization name is honeybadger.
### 2. Set the API token
[Section titled “2. Set the API token”](#2-set-the-api-token)
Your API Token can be found in the Shortcut UI by clicking on the gear icon for settings, choosing the Your Account link, then choosing the API Tokens link. Choose a name for your token (like Honeybadger) and click Generate Token. Copy the highlighted token, and paste that in the API Token field.
### 3. Fetch custom fields and workflow data
[Section titled “3. Fetch custom fields and workflow data”](#3-fetch-custom-fields-and-workflow-data)
Click the Fetch custom fields and workflow data button to make a request to the Shortcut API to get your list of teams, custom fields, and workflow states. This will populate and enable the remaining dropdowns on the form.
### 4. Choose the team, custom fields, and workflow states
[Section titled “4. Choose the team, custom fields, and workflow states”](#4-choose-the-team-custom-fields-and-workflow-states)
Each Honeybadger project is associated with one Shortcut team, and you can make that choice here. In addition, you may also specify custom field choices to apply to your stories. You can also choose which of your Shortcut workflow states will be chosen for stories when they are marked as resolved or unresolved. The stories will be updated to those states if you also enable the respective Error Events options.
## Creating stories from the UI
[Section titled “Creating stories from the UI”](#creating-stories-from-the-ui)
Users can create stories in Shortcut by clicking the Create Story button on the error detail page in the Honeybadger UI. By default, these stories will be created as the Shortcut user whose API Token is configured in the integration settings. Users can have stories associated with their own Shortcut account by getting an API Token as described previously and adding it to their [authentication settings](https://app.honeybadger.io/users/edit#authentication).
# Slack
> Connect Honeybadger to Slack to receive real-time application monitoring alerts and resolve issues directly from your team's channels.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the integration for Slack
[Section titled “1. Select the integration for Slack”](#1-select-the-integration-for-slack)
When you click on the link to add Slack to your project, you will be redirected to Slack to approve the connection to your Slack team. After you choose the channel to receive Honeybadger messages and click the Authorize button, you will be redirected back to Honeybadger to finish editing the optional channel settings.
### 2. Save
[Section titled “2. Save”](#2-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
## Interactive messages
[Section titled “Interactive messages”](#interactive-messages)
Messages about errors include a button to resolve or reopen the error:
The first time you click one of the buttons, you will be given a link that will allow you to connect your Slack account to your Honeybadger account. This connection only needs to be done once, and then you will be able to use the buttons and interact with the bot.
## Using the bot
[Section titled “Using the bot”](#using-the-bot)
Once you have installed the Honeybadger app for Slack, you will have a Honeybadger bot available to your Slack team. You can message the bot directly or you can invite it to join a channel and address it… either way, it understands the following commands:
| Command | Description |
| ---------------------------------- | ------------------------------------------------------------------------------------------- |
| **help** | Get help :) |
| **show project *\*** | Returns a list of faults that occurred recently in the *Project Name* project. |
| **show fault *\*** | See details about the requested fault. The fault number can be found in the Honeybadger UI. |
| **resolve fault *\*** | Mark the specified fault as resolved. |
| **reopen fault *\*** | Mark the specified fault as reopened. |
# Splunk On-Call
> Connect Honeybadger to Splunk On-Call to route critical errors and application monitoring alerts through your incident response and on-call workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Splunk On-Call integration
[Section titled “1. Select the Splunk On-Call integration”](#1-select-the-splunk-on-call-integration)
 
### 2. Set the API key
[Section titled “2. Set the API key”](#2-set-the-api-key)
You can generate a Splunk On-Call API key on the Splunk On-Call integrations page.
### 3. Set the routing key (optional)
[Section titled “3. Set the routing key (optional)”](#3-set-the-routing-key-optional)
If you like, you can specify an arbitrary routing key for use by Splunk On-Call.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Sprintly
> Connect Honeybadger to Sprintly to automatically create defects from errors and track bug fixes in your workflow.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Sprintly integration
[Section titled “1. Select the Sprintly integration”](#1-select-the-sprintly-integration)
 
### 2. Set the email & API key
[Section titled “2. Set the email & API key”](#2-set-the-email--api-key)
You can get your Sprintly API key by logging into Sprintly and going to your Profile page. The key is at the bottom.
### 3. Set the product ID
[Section titled “3. Set the product ID”](#3-set-the-product-id)
You can find your product’s id by examining the URL. If your product’s url is `sprint.ly/product/777` then the product id is “777”.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! You can test the integration by clicking “Test”. Otherwise, just save it and you’re ready to go.
# Trello
> Connect Honeybadger to Trello to automatically create cards from errors and track bug fixes on your Trello boards.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Trello integration
[Section titled “1. Select the Trello integration”](#1-select-the-trello-integration)
 
### 2. Connect your Trello account
[Section titled “2. Connect your Trello account”](#2-connect-your-trello-account)
Just click the button to connect to trello via OAuth.
### 3. Select the board and list
[Section titled “3. Select the board and list”](#3-select-the-board-and-list)
These two dropdowns will be populated when you connect your account.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! Hit save and you’re good to go.
# Webhook
> Configure custom webhooks to send Honeybadger error notifications and events to any third-party service or API.
Honeybadger sends webhooks when certain events occur in your Honeybadger projects. Each event type has a specific payload structure with relevant data about the event.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. Select the Webhook integration
[Section titled “1. Select the Webhook integration”](#1-select-the-webhook-integration)
 
### 2. Set the URL for your webhook
[Section titled “2. Set the URL for your webhook”](#2-set-the-url-for-your-webhook)
We’ll post notifications to this URL. Make sure to include the protocol: e.g., `https://mysite.com/hook`.
Make sure you have a service running that can accept POST requests, and hopefully do something interesting with JSON payloads like this one:
```plaintext
{
"event":"occurred",
"message":"[Crywolf/test] RuntimeError - oops",
"fault":{
"id":3151009,
"project_id":1717,
"klass":"RuntimeError",
"component":null,
"action":null,
"environment":"development",
"resolved":true,
"ignored":false,
"created_at":"2014-01-08T18:55:48Z",
"comments_count":1,
"message":"oops",
"notices_count":9,
"last_notice_at":"2014-01-08T19:02:21Z"
}
}
```
See [Event Payloads](#payload-structure) for all available events and their structure.
### 3. Set a bearer token (optional)
[Section titled “3. Set a bearer token (optional)”](#3-set-a-bearer-token-optional)
Every webhook we send already includes a [`Honeybadger-Token` header](/resources/security/#authenticating-requests-from-honeybadger) you can use to verify that the request came from us.
Some services reject a request outright unless it arrives with an `Authorization` header, before your own code ever sees it. If yours is one of them, put the key in the **Bearer token** field and we’ll send it with every request:
```plaintext
Authorization: Bearer your-token
```
Leave the field blank if you don’t need it. The token is encrypted at rest, and it’s masked when you come back to the form later.
### 4. Save
[Section titled “4. Save”](#4-save)
That’s it! Hit save and you’re good to go.
## Payload structure
[Section titled “Payload structure”](#payload-structure)
Each event payload is sent as a JSON object with the following properties:
* `event` - The type of event (e.g., `occurred`, `resolved`, `deployed`)
* `message` - A human-readable description of the event
* Additional event-specific data (varies by event type)
## Event payloads
[Section titled “Event payloads”](#event-payloads)
The following events are supported by the Webhook integration:
### [`assigned`](/guides/integrations/payloads/assigned/)
[Section titled “assigned”](#assigned)
Sent when an error is assigned to a user.
**Top-level properties:** `event`, `message`, `actor`, `fault`, `assignee`
### [`cert_will_expire`](/guides/integrations/payloads/cert_will_expire/)
[Section titled “cert\_will\_expire”](#cert_will_expire)
Sent when an SSL certificate is about to expire.
**Top-level properties:** `event`, `message`, `project`, `site`
### [`check_in_missing`](/guides/integrations/payloads/check_in_missing/)
[Section titled “check\_in\_missing”](#check_in_missing)
Sent when an expected check-in is missing.
**Top-level properties:** `event`, `message`, `project`, `check_in`
### [`check_in_reporting`](/guides/integrations/payloads/check_in_reporting/)
[Section titled “check\_in\_reporting”](#check_in_reporting)
Sent when a check-in reports successfully.
**Top-level properties:** `event`, `message`, `project`, `check_in`
### [`commented`](/guides/integrations/payloads/commented/)
[Section titled “commented”](#commented)
Sent when a comment is added to an error.
**Top-level properties:** `event`, `message`, `actor`, `fault`, `comment`
### [`deployed`](/guides/integrations/payloads/deployed/)
[Section titled “deployed”](#deployed)
Sent when a deployment is recorded.
**Top-level properties:** `event`, `message`, `project`, `deploy`
### [`down`](/guides/integrations/payloads/down/)
[Section titled “down”](#down)
Sent when an uptime check fails.
**Top-level properties:** `event`, `message`, `project`, `site`, `outage`
### [`occurred`](/guides/integrations/payloads/occurred/)
[Section titled “occurred”](#occurred)
Sent when an error occurs.
**Top-level properties:** `event`, `message`, `project`, `fault`, `notice`
### [`rate_exceeded`](/guides/integrations/payloads/rate_exceeded/)
[Section titled “rate\_exceeded”](#rate_exceeded)
Sent when error rate threshold is exceeded.
**Top-level properties:** `event`, `message`, `project`, `fault`
### [`resolved`](/guides/integrations/payloads/resolved/)
[Section titled “resolved”](#resolved)
Sent when an error is marked as resolved.
**Top-level properties:** `event`, `message`, `project`, `fault`
### [`unresolved`](/guides/integrations/payloads/unresolved/)
[Section titled “unresolved”](#unresolved)
Sent when a resolved error occurs again.
**Top-level properties:** `event`, `message`, `project`, `fault`
### [`up`](/guides/integrations/payloads/up/)
[Section titled “up”](#up)
Sent when an uptime check succeeds after being down.
**Top-level properties:** `event`, `message`, `project`, `site`, `outage`
### [`volume_spike`](/guides/integrations/payloads/volume_spike/)
[Section titled “volume\_spike”](#volume_spike)
Sent when a project’s error volume spikes above its learned baseline.
**Top-level properties:** `event`, `message`, `project`, `volume_spike`
# Zulip
> Connect Honeybadger to Zulip to receive real-time application monitoring alerts directly in your team's streams.
Users with administrative privileges can find this integration below the list of personal alert integrations on the Alerts & Integrations tab of the Project Settings page.
## Setup
[Section titled “Setup”](#setup)
### 1. In Zulip, create a new incoming webhook bot.
[Section titled “1. In Zulip, create a new incoming webhook bot.”](#1-in-zulip-create-a-new-incoming-webhook-bot)
You’ll need to create a new Incoming Webhook Bot in Zulip. This is done by going to the **Settings** page of your Zulip organization and selecting **Bots** from the left-hand menu.
### 2. In Honeybadger, locate the Zulip integration.
[Section titled “2. In Honeybadger, locate the Zulip integration.”](#2-in-honeybadger-locate-the-zulip-integration)
In the project settings, click on the **Integrations** tab where you’ll find the Zulip integration.
### 3. Fill in the required fields and save.
[Section titled “3. Fill in the required fields and save.”](#3-fill-in-the-required-fields-and-save)
Fill in the required fields which you generated in step 1. Configure which notifications you wish to receive and then save.
You can also click on the “Test this integration” button to send a test notification to your Zulip stream. This is a great way to ensure that everything is set up correctly before you start receiving real notifications.
# Projects
> Projects contain your errors, check-ins & uptime.
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
[Section titled “General project settings”](#general-project-settings)
The General tab holds the project’s core settings.
### Error retention
[Section titled “Error retention”](#error-retention)
**Error retention** is the number of days an error is kept after its last occurrence. The maximum for your project is shown below the field. Lower it if you need to enforce a data retention policy for compliance reasons. Error data, including any context you send, is deleted once the retention period expires.
### Resolve errors on deploy
[Section titled “Resolve errors on deploy”](#resolve-errors-on-deploy)
The **Resolve errors on deploy** setting automatically marks all errors “resolved” when you [report a deployment](/api/reporting-deployments/), 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](/guides/errors/#resolve-on-deploy) on the error page.
### Linking to your users and code
[Section titled “Linking to your users and code”](#linking-to-your-users-and-code)
Honeybadger can only show what your app sends it, but these settings let the error detail page connect that data back to the systems you already use: your admin tools, your source repository, and your own domains.
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 **Source URL** field customizes the source code links in error backtraces. If you use the [GitHub integration](/guides/integrations/github/), links are generated automatically and you can leave this blank. For other hosts, enter a URL template using the `[sha]`, `[file]`, `[line]`, and `[method]` placeholders. For example:
```plaintext
https://github.com/your-username/your-repo/blob/[sha]/[file]#L[line]
```
**Linkable domains** restricts which request URLs are rendered as clickable links on the error detail page. Enter a space-delimited list of domains, or leave it blank to link all URLs.
### Throttle
[Section titled “Throttle”](#throttle)
The **Throttle** field allows you to set a 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
[Section titled “Public error pages”](#public-error-pages)
You can make an error public by clicking “Share URL” in the [actions area](/guides/errors/#error-actions) 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 → General → 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](#project-actions).
If you never want errors shared outside your team, check **Disable public links**. This removes the “Share URL” button from error pages and also disables the public dashboard.
### Transfer project
[Section titled “Transfer project”](#transfer-project)
You can transfer a project to another account by choosing it from the dropdown. Before you do, note that:
* The new owner becomes responsible for payment.
* You keep access to the project unless the new owner removes you.
* The project is removed from any teams it was assigned to, so members of those teams lose access.
To move *everything* (projects, teams, and billing) to another user, add them as an account owner on the Account Settings page instead. See [Accounts](/guides/accounts/) for details.
### Delete project
[Section titled “Delete project”](#delete-project)
At the bottom of the General tab is the project delete button. Deleting a project removes all of its data immediately and cannot be undone.
## Insights
[Section titled “Insights”](#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](/guides/insights/) documentation page.
## Users
[Section titled “Users”](#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](/guides/user-management/) documentation page.
## Environments
[Section titled “Environments”](#environments)
The Environments tab lists every environment that has reported errors to the project. Environments are added automatically as errors arrive from them, so you don’t need to create them ahead of time.
For each environment, you can:
* **Toggle notifications** with the bell icon. Turning notifications off for an environment (such as `development` or `staging`) keeps its errors in your project without alerting your team.
* **Forget the environment** with the trash icon. This removes the environment from the list. It will be re-added if the environment reports another error.
If you deploy to many environments (for example, one per pull request or per-customer instance), use the search box to filter the list by name. Long lists are paginated. Select one or more environments with the checkboxes, then use the **Bulk actions** dropdown to toggle notifications or forget all of the selected environments at once.
Environments can also be managed with the [Environments API](/api/environments/) or the [`hb environments` CLI command](/resources/cli/environments/).
## Alerts & integrations
[Section titled “Alerts & integrations”](#alerts--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](/guides/integrations/) documentation page.
## API keys
[Section titled “API keys”](#api-keys)
Project API keys grant access to our reporting APIs. The list of reporting endpoints is in our [API docs](/api/). If an API key is leaked or misused, you can rotate your key by adding a new key and removing the old one.
Note
Project API keys don’t grant access to our REST API. You will need to use your [personal token](/api/getting-started/#authentication) for that.
## Project actions
[Section titled “Project actions”](#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
[Section titled “Source maps”](#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](/lib/javascript/errors/using-source-maps/) documentation page.
## One language per project
[Section titled “One language per project”](#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.
# Reports
> Viewing and understanding reports.
The Reports page of a project includes summary charts of error data grouped by location, class, day, and affected user, as well as a summary of the project’s uptime checks.
Clicking on a bar in one of the bar charts will take you to a search for errors matching the selected location, class, or user.
# Status pages
> Give users insight into your system status.
Your Honeybadger account comes with customizable status pages. Give your users insights into the working state of your system by connecting uptime checks or providing updates during problems via incidents.
Here’s a [live example](https://uptime.honeybadger.io/) of our Honeybadger status page.
Tip
You can find your status pages and create a new one [here](https://app.honeybadger.io/status_pages).
## Customizing your status page
[Section titled “Customizing your status page”](#customizing-your-status-page)
You can customize your status page with your company logo and favicon from *Status Pages* → *Your Status Page* → *Edit*. If you upload a dark logo variant, we’ll use that version with our built-in dark mode theme.
For more control over the look and feel of your status page, see the “Custom CSS” option under *Customization* at the bottom of the settings form.
## Adding a custom domain
[Section titled “Adding a custom domain”](#adding-a-custom-domain)
To add a custom domain, enter the domain (without the http(s)://) when editing your status page. To verify your domain, add a CNAME DNS record with a value of **status.hbuptime.com**. For example, if your domain is status.example.com, then you should add the following CNAME through your DNS provider (Google Domains, Amazon Route 53, GoDaddy, etc.):
| Record type | Label/Host field | Time To Live (TTL) | Destination/value |
| ----------- | ------------------ | --------------------------- | ------------------- |
| CNAME | status.example.com | default is fine (i.e. 3600) | status.hbuptime.com |
**Once the record has been created, click the “Verify” button under your status page back in Honeybadger:**
Now you can visit your domain in a browser. We automatically generate SSL certificates; it should be ready to go on the first visit, but in some cases you may need to refresh a few times. If you have trouble, don’t hesitate to [get in touch](https://www.honeybadger.io/contact/).
## Uptime checks
[Section titled “Uptime checks”](#uptime-checks)
Connect any currently running uptime checks to your status page if you’d like to share your uptime status with the world. Status pages may include uptime checks across all of the projects in your account.
### Connecting checks
[Section titled “Connecting checks”](#connecting-checks)
While editing your status page, toggle which uptime checks you would like included with your status page.
Give each uptime check an optional display name if you want to customize the name displayed publicly.
That’s it! We will show each uptime check’s current status and history on your public status page.
## Incidents
[Section titled “Incidents”](#incidents)
An incident is an effective way to communicate system issues to your users. It can also inform your users of upcoming planned maintenance or downtime.
Conceptually, an incident is a container for timestamped updates that describe the context surrounding a problem affecting your system. An incident can be as simple as a single update that explains some minor downtime, or it can span multiple days with many updates, each representing the changing severity and status of the incident.
### Creating incidents
[Section titled “Creating incidents”](#creating-incidents)
We provide three scenarios when creating incidents: `Current`, `Scheduled Maintenance`, and `Retroactive`:
#### Current
[Section titled “Current”](#current)
Current incidents start with one update and are typically open after creation (meaning you would not select “Resolved” as the starting status.)
#### Scheduled maintenance
[Section titled “Scheduled maintenance”](#scheduled-maintenance)
Scheduled Maintenance incidents are notable because you can queue updates for later posting.
Note
This is the only place you can submit an update to post in the future.
You can create up to three future updates, which we will post at the supplied `Start Time`. Typically you will send out a `Maintenance scheduled` update that describes the type of maintenance you will perform and when. After that, we have both `In Maintenance` and `Maintenence complete` statuses that you can queue up as individual updates. It’s up to you how much lead time to give your users, based on how you stagger the timing of each update.
If you complete your maintenance sooner than expected, you can always edit the queued update and use the “send now?” button to post the update immediately.
#### Retroactive
[Section titled “Retroactive”](#retroactive)
Retroactive incidents give you a tool to create multiple incident updates in one operation. You can create a closed incident from months ago or an open incident that started minutes ago. If you don’t end with a [closing update](#open-and-closed-incidents), the incident will be considered open.
A retroactive incident also allows you to craft a single [announcement](#announcing-updates) message to accompany your incident updates. This way, you have the option to summarize the incident yet keep each event as separate updates.
Note
You can not announce each update individually via a retroactive incident.
### Posting an update
[Section titled “Posting an update”](#posting-an-update)
When you are ready to inform your users with an update to your incident, click the button in the incident header and fill in your update inline.
### Severity and status
[Section titled “Severity and status”](#severity-and-status)
When you create an incident or post a new update, you choose a `status` and `severity`. `status` describes where you are in the process of resolving your incident and `severity` describes how your system is currently affected by the incident.
Scheduled maintenance incidents have a special set of statuses. You can, however, post an update during scheduled maintenance with an incident status, say if things go awry.
### Open and closed incidents
[Section titled “Open and closed incidents”](#open-and-closed-incidents)
Note
An incident update with a `Resolved` or `Maintenance complete` status will close the containing incident.
An incident, when created, is considered “open.” It will be prominently displayed on your internal status page and made visible as an “active incident” on your public status page. When you provide an update containing a status that closes the incident, it will be “closed” and moved to the historical list of closed incidents.
Even if you have closed an incident with an update, you can always re-open it by posting an update with a new status. While this is possible and useful if something comes up right after closing an incident, we recommend you open a new incident if a significant amount of time has passed.
### Announcing updates
[Section titled “Announcing updates”](#announcing-updates)
We provide the option to connect your status page to a Twitter account (while editing the status page). Linking your Twitter enables us to announce your incident updates to the world. Once connected, a new “Announce” option will be available while crafting any incident updates.
If your account is on a Business or Enterprise plan, the “Announce” option is also available without a connected Twitter account, and it sends the update to your [email subscribers](#email-subscriptions) as well.
## Email subscriptions
[Section titled “Email subscriptions”](#email-subscriptions)
Visitors to your status page can subscribe by email to receive a message whenever you announce an incident update or a scheduled maintenance event. No setup is required: when your account is on a Business or Enterprise plan, a “Subscribe” button appears automatically on each of your status pages.
### How subscribing works
[Section titled “How subscribing works”](#how-subscribing-works)
1. A visitor enters their email address in the Subscribe form.
2. We send a confirmation email from `notifications@honeybadger.io`. The subscription isn’t active until the visitor clicks the confirmation link (double opt-in). Unconfirmed subscriptions expire after 7 days.
3. Once confirmed, the subscriber receives an email each time you post an update with the “Announce” option checked. Confirming doesn’t send anything by itself—new subscribers hear from you the next time you announce an update.
Every notification email includes a one-click unsubscribe link, and subscribers can unsubscribe at any time. Addresses that hard-bounce or report a message as spam are unsubscribed automatically.
### What gets sent
[Section titled “What gets sent”](#what-gets-sent)
* Updates to [current](#current) incidents and [scheduled maintenance](#scheduled-maintenance) with the “Announce” option checked get sent
* Scheduled events send an email at the event’s start time
* Multiple updates to the same incident posted within a minute or two are combined into a single email, so a flurry of quick edits doesn’t flood your subscribers’ inboxes.
### What doesn’t get sent
[Section titled “What doesn’t get sent”](#what-doesnt-get-sent)
* Updates posted with the “Announce” option unchecked are not sent.
* [Retroactive](#retroactive) incidents are never emailed to subscribers.
### Managing subscribers
[Section titled “Managing subscribers”](#managing-subscribers)
Your status page’s info page in Honeybadger shows an “Email Subscribers” card with the current subscriber count. Click “Manage” to see the list of confirmed subscribers and remove any of them. A removed subscriber will not receive further emails and can’t re-subscribe with the same address.
Each status page can have up to 500 subscribers (pending confirmations count toward this limit).
### Subscribing to password-protected pages
[Section titled “Subscribing to password-protected pages”](#subscribing-to-password-protected-pages)
If your status page is [password protected](#password-protection), visitors must enter the page’s username and password before they can subscribe. To avoid leaking private details, notification emails for protected pages contain only a generic “status changed” message and a link back to the page, not the incident text.
### Plan changes
[Section titled “Plan changes”](#plan-changes)
If your account moves to a plan that doesn’t include this feature, the Subscribe button disappears and no further emails are sent. Your subscriber list is kept, and notifications resume for future updates if you upgrade again.
## Password protection
[Section titled “Password protection”](#password-protection)
Honeybadger status pages can be configured to require a username and password before they can be viewed. This is useful for private or internal status pages that only those in your company should be able to view.
To enable password protection, edit your status page and check the “Require a username and password” checkbox. Set your desired username and password in the fields below. If you are using a password manager, be sure you don’t overwrite your login information for the Honeybadger app itself.
## Embedding status updates
[Section titled “Embedding status updates”](#embedding-status-updates)
Incident management often requires communicating outages with your customers. With the status page embed feature, you can keep your users up to date when they visit your website.
### Setup and usage
[Section titled “Setup and usage”](#setup-and-usage)
Each of your status pages will have their own unique installation instructions, go to your status page info page, you’ll find the link towards the bottom of the page.
Copy the snippet of code and paste it anywhere in the HTML of your site.
Like the status page, when you start an incident, the embed feature will always display the latest update to your users.
### Customization
[Section titled “Customization”](#customization)
The embed pop-up can be customized to better fit the look and feel of your site. Use the customization tool to adjust how you want it too look. When you are ready, copy and paste the HTML snippet onto your site. Here are some of the options you can customize:
* **Position** — Change where the popup will appear: bottom left (default), bottom right, top left, or top right.
* **Font color** — Set the font color of the text. Any valid CSS font color value can be used.
* **Background color** — Set the background color of the pop up. Any valid CSS color value can be used.
* **Close button behavior** — By default, the pop up will always show on page load. You can enable the persist feature so that when your visitor closes the pop-up, a browser cookie will be set so that it doesn’t pop up again until your next update. The cookie gets set to expire upon browser or session close.
### Displaying scheduled maintenance
[Section titled “Displaying scheduled maintenance”](#displaying-scheduled-maintenance)
The status page embed works great with the schedule maintenance feature. Create your scheduled maintenance messages as noted above. Once the “Start Time” for your messages have passed, your visitors will see the latest update on your site via the embed pop up.
### Displaying non-incident messages
[Section titled “Displaying non-incident messages”](#displaying-non-incident-messages)
If you have both an ongoing incident and a non-incident message enabled at the same time, the incident update messages will take precendence over the non-incident message.
### Password-protected status pages
[Section titled “Password-protected status pages”](#password-protected-status-pages)
If your account has the password protected feature and you have enabled the feature for your status page, the embed feature will become disabled. To use the embed feature, you’ll need to disable the password protection feature.
## SEO and analytics
[Section titled “SEO and analytics”](#seo-and-analytics)
### Search engine indexing
[Section titled “Search engine indexing”](#search-engine-indexing)
By default, search engines can find and index your status pages—meaning they can end up in search results. You can turn off this behavior by checking the “Do not allow search engines to index my search page” checkbox. Search engines may take time to update their results if your status page is already indexed.
If you want added protection and privacy, look at our [Password Protection](#password-protection) feature to prevent unwanted access to your Status Page.
### Google Analytics
[Section titled “Google Analytics”](#google-analytics)
You can also add your Google Analytics ID to enable Google Analytics tracking for your Status Page.
# Uptime monitoring
> Get notified when your API is unresponsive.
Your Honeybadger account comes with uptime monitoring. Our geographically distributed network of friendly robots will ping your site every few minutes. If a check fails, we’ll let you know.
You can set up fairly sophisticated checks based on the HTTP status code, or the response body.
## Setup
[Section titled “Setup”](#setup)
Note
Enabling bot protection on Cloudflare-hosted websites may prevent uptime checks from working.
When creating an uptime check, just tell us what URL you want monitored. You can choose what counts as a success response from these options:
* **Success** - notifies you that your site is down when your server responds with a non-20x status code. When in doubt, this is the one you probably want.
* **Exact** - prompts you to enter an HTTP status code. If you entered 302 it would ensure that the server responds with a 302 status code.
* **Response body includes string** - prompts you for a string (i.e. “Error”) and notifies you when the response body matches.
* **Response body excludes string** - prompts you for a string and notifies you if the response body does *not* match.
* **Response body matches JMESPath expression** - allows you to specify a [JMESPath](https://jmespath.org) expression that is evaluated against the JSON returned in the response. For example, an expression like ``queue.depth < `10` ``will evaluate to true for a JSON response like `{"queue":{"depth":2}}`.
You have the option to specify response header checks. For example, you can check if the response header `Content-Type` contains `application/json`, or whether the `location` header redirects to the correct URL. All response header checks must evaluate to true for the check to be considered successful, and the check values are case-sensitive.
You can also choose to send custom request headers or a custom request body, check the validity of the SSL certificate, and select which locations should be used for monitoring.
You can optionally give each of your uptime checks a custom name, which will be the default label for when included on a Status Page.
Hit “save” and you’re done!
### Timeouts
[Section titled “Timeouts”](#timeouts)
Each uptime check has a timeout of 30 seconds by default. If your URL does not respond within this time, it will be marked as failed for that location.
Business and Enterprise customers can customize the timeout setting for their uptime checks. The timeout field allows you to specify how long the uptime check will wait for a response before reporting the site as down. The default is 30 seconds and the maximum is 120 seconds.
## Outage notifications
[Section titled “Outage notifications”](#outage-notifications)
When your site goes down, we’ll notify you with all the details about what went wrong, including how your check failed. For example, you will see receive a notification like this one when the uptime check expected a successful status code but returned a 500.
By default, the notification is sent after half of the locations report a failing check. This means that if you are using five locations, there would need to be three failures in a row before you would receive an alert. You can override this default by specifying a value for the Outage Threshold field.
## Outage details
[Section titled “Outage details”](#outage-details)
When you get a notification that a check has failed, we’ll also link you to a web page with details. This detailed view can be accessed by clicking the “View” link for any particular uptime check in the UI.
At the top, the average load time over the past week will be displayed, as well as the uptime check itself.
Scrolling down, you can see the uptime on a percentage-monthly basis.
Finally, the most recent checks will be displayed, and below that, a list of the uptime check’s most recent outages.
## SSL certificate warnings
[Section titled “SSL certificate warnings”](#ssl-certificate-warnings)
We’ll send you a daily warning when your SSL certificates are about to expire. To enable warnings, check the “Check SSL certificate” option when editing your uptime check:
You should also check the “When my SSL certificates are about to expire” event when editing [alerts and integrations](/guides/integrations/):
## Status page integration
[Section titled “Status page integration”](#status-page-integration)
Check out our [Status pages](/guides/status-pages/#uptime-checks) feature for presenting your uptime checks to your users.
# User management
> User membership for projects, teams, and accounts.
Honeybadger is much more fun when you bring some friends to the party. The easiest way to do so is to assign projects to a team, then [invite users to join your team](#how-to-invite-a-team-user).
## What can users do?
[Section titled “What can users do?”](#what-can-users-do)
Our paid plans let you invite your co-workers to collaborate on your projects. The table below gives examples of what different kinds of users can do.
| | Account Owner | Admin | Member |
| --------------------------------------------------------- | :-----------: | :---: | :----: |
| Work with errors, uptime, check-ins, etc. | ✅ | ✅ | ✅ |
| Configure personal alerts, like email | ✅ | ✅ | ✅ |
| Configure chat, issue tracker and repository integrations | ✅ | ✅ | |
| Invite and manage users | ✅ | ✅ | |
| Assign projects to teams | ✅ | ✅ | |
| Manage account billing | ✅ | ✅ | |
| Transfer projects to another account | ✅ | | |
| Cancel subscription and delete account | ✅ | | |
## Inviting users
[Section titled “Inviting users”](#inviting-users)
You have three options when inviting users. You can invite them…
* **To a project:** Inviting a user directly to your project is the easiest route, as long as you only have one or two projects.
* **To a team, which has been assigned the project:** This is the best route if you have more than a handful of users and projects.
* **To an account:** Users are automatically added to an account when added to a project or team, but adding users to an account is the way to go when you want those users to have the Owner role.
### How to invite a project user
[Section titled “How to invite a project user”](#how-to-invite-a-project-user)
To invite a project user, go to the “Settings” tab when viewing a project and click on “Users” in the sidebar. Use the form to enter their email address and choose their permissions for the project.
Your invitee will get an email with instructions on how to proceed.
### How to invite a team user
[Section titled “How to invite a team user”](#how-to-invite-a-team-user)
View the Users tab on the team detail page to invite a team user. You’ll see a form where you can enter their email address and choose their permissions for the team.
If you’re not sure which team is associated with a project, you can see the list of teams that are connected to a project on the Users tab of the Project Settings page.
### How to invite an account user
[Section titled “How to invite an account user”](#how-to-invite-an-account-user)
Go to the Users tab of the [account settings](/guides/accounts/#account-settings) page to add a new user to your account:
When adding a user, you can choose which role the user should have (Owner, Admin, or Member), and which teams that user will be able to access. As with project and team invitations, users will receive an email with a link to join the account.
## SAML SSO
[Section titled “SAML SSO”](#saml-sso)
You can optionally provide single-sign on (SSO) to your team members via one of our supported SSO providers: Google Apps for Work, Okta, or OneLogin. Provider-specific configuration instructions are found on the Authentication tab in [account settings](/guides/accounts/#account-settings). Generally speaking, the configuration process goes like this:
1. Create a custom SAML app in your provider’s admin dashboard.
2. Download the IdP metadata from your provider and add it to your Honeybadger SAML configuration.
3. Configure the custom SAML app with the information provided on the SAML configuration page in the app.
After those steps are completed, your team members can log in through your SSO provider’s dashboard, or they can enter the SSO name provided in the SAML configuration when signing in to Honeybadger.
### Role mapping
[Section titled “Role mapping”](#role-mapping)
You can assign account roles automatically based on a SAML assertion attribute, such as a Google Workspace group. In the **Role Mapping** section of your SAML configuration, enter the name of the attribute that carries group membership (e.g., `groups`), then add rules that map attribute values to account roles.
On each SAML login, we compare the values of the configured attribute against your rules and apply the highest-privilege matching role (Owner over Admin over Member). A few things to keep in mind:
* Values are matched exactly (case-insensitive) — a rule’s value must equal what your identity provider sends. To help you write rules, the SAML configuration page displays the attribute names and values from the most recent sign-in.
* Users who match no rule keep their current role — removing a user from all mapped groups does not demote them.
* Role mapping will never demote the account’s only remaining Owner, and only account Owners can add or change rules that grant the Owner role.
### Team mapping
[Section titled “Team mapping”](#team-mapping)
You can also manage team memberships and permissions from your identity provider. In the **Team Mapping** section of your SAML configuration (shown when your account has at least one team), add rules that assign an attribute value — a group, for example — to a team and a permission level (Member or Admin). Team mapping rules use the attribute name configured in the **Role Mapping** section, so be sure to set that first.
On each SAML login, the user’s SAML-managed team memberships are synced from their groups:
* When an attribute value matches a rule, the user is added to the mapped team with the mapped permission.
* When the user’s groups (or your rules) change, their team permission is updated in place — their per-project notification settings are preserved.
* When the user no longer has a group that maps to a team, they are removed from that team.
* If multiple rules match the same team with different permissions, Admin wins over Member.
Team mapping only manages memberships that it created. Memberships created by a manual invitation or by the **Team Access** option (which automatically adds all SSO users to the selected teams) are never modified or removed by team mapping. If a user already belongs to a team via one of those, a team-mapping rule won’t change their permission. When a team has both a mapping rule and **Team Access** enabled, a user who loses their mapped group stays on the team as a regular Team Access member instead of being removed.
## Restricted authentication
[Section titled “Restricted authentication”](#restricted-authentication)
We provide more control over your users’ login sources when enabling “Restricted Authentication” for your account. You can manage restricted authentication from the Authentication tab in [account settings](/guides/accounts/#account-settings). A common use case is to require users to use SSO instead of being able to log in with a password.
#### Auth sources
[Section titled “Auth sources”](#auth-sources)
You can select which authentication sources are allowed to access your account.
If you require only SAML login, you can disable all other available sources. When a user accesses your account via password, we will redirect them to your custom sign-in page with a link to your SAML provider.
#### Session duration
[Section titled “Session duration”](#session-duration)
You also have control of your users’ session duration, per auth source. For example, daily reauthentication with your SAML provider can be achieved by updating the “Session expire duration” for your SAML auth source.
#### Custom sign-in page
[Section titled “Custom sign-in page”](#custom-sign-in-page)
Restricted auth accounts have access to a custom sign-in page. We will only show your active auth sources as sign-in options.
## Multi-factor authentication
[Section titled “Multi-factor authentication”](#multi-factor-authentication)
Honeybadger supports multi-factor authentication (also known as two-factor authentication, 2FA, or MFA) via Google Authenticator, Authy, and similar 2FA providers. Account owners can require multi-factor authentication for all users from the Authentication tab in [account settings](/guides/accounts/#account-settings).
When enabled, we’ll notify the users who need to set it up via email, and prompt them to enable it on their next login.
# User settings
> Your personal preferences.
Note
For information about inviting users to your projects or teams, check out our [User Management Guide](/guides/user-management/). This guide is meant to help people configure their personal preferences when they’ve already joined a project.
User accounts in Honeybadger are very similar to those in GitHub. Each user is his or her own person. While project admins can configure project-level integrations like Slack, each individual user has complete control over their personal alerts and other user settings on the [User Settings](https://app.honeybadger.io/users/edit) page.
Here are some examples of “personal settings”:
* Name and connected email
* Localized date and time preferences
* Connection to GitHub and other 3rd-party accounts
* Daily and weekly digest email settings for all projects
* Local editor selection for links displayed on backtraces
The user settings page is also where you can:
* Add or remove connections for mobile devices
* Leave projects where you are not the sole owner
* Set up local editors for your projects
* Cancel the user account
## Configuring personal alerts
[Section titled “Configuring personal alerts”](#configuring-personal-alerts)
Alerts sent via email, SMS and our mobile apps are considered “personal” integrations. You and only you control which personal integrations are enabled and which events they receive. As you log in to the mobile apps on new devices, they are added to the personal integrations list for all the projects you can access.
You have a separate set of alert preferences for each project you work with. One way to edit them is by going to each project’s settings page and clicking on the “Alerts” tab. There’s a section for “Personal Alerts.”
While the account owner can see what notifications other users in the accounts have enabled, they cannot customize them.
### Mobile device connections
[Section titled “Mobile device connections”](#mobile-device-connections)
From the User Settings page, you can customize your connected mobile devices via the “Mobile Devices” tab on the sidebar. Here you will find links to download the Honeybadger app so you can connect your devices to receive important alerts on the go.
### SMS phone numbers
[Section titled “SMS phone numbers”](#sms-phone-numbers)
Honeybadger sends SMS alerts from a pool of phone numbers. To ensure that you receive alerts, download our vCard and add it to your contacts on your desktop or smartphone:
[Download Honeybadger Outgoing Numbers vCard](/Honeybadger%20Outgoing%20Numbers.vcf)
In iOS you can optionally [configure a custom text tone and enable the *Emergency Bypass* option](https://support.apple.com/guide/iphone/allow-or-silence-notifications-for-a-focus-iph21d43af5b/17.0/ios/17.0#iph68077cc0d) for the Honeybadger contact. Android has a [similar option](https://support.google.com/android/thread/219866813?hl=en\&msgid=220251463). This will ensure that you receive alerts even when your phone is in *Do Not Disturb* mode.
Our current outgoing numbers (from the [vCard](/Honeybadger%20Outgoing%20Numbers.vcf)) are:
* (206) 535-1618
* (206) 203-4914
* (206) 203-6150
* (206) 203-8212
* (206) 203-1222
* (206) 203-5571
Please note that these numbers are subject to change. We recommend checking this page periodically for updates.
*Last updated: 2024-03-20*
### Configuring alerts across multiple projects
[Section titled “Configuring alerts across multiple projects”](#configuring-alerts-across-multiple-projects)
If you work with lots of projects, it can be a hassle to visit each settings page. That’s why we’ve added a single page UI where you can enable/disable all personal notifications in one place. This is available on the [Notifications tab](https://app.honeybadger.io/users/edit#notifications) of the [User Settings](https://app.honeybadger.io/users/edit) page.
To access the detailed project notification options, click the project links displayed on this page to customize what kind of alerts you can receive.
## Connected apps
[Section titled “Connected apps”](#connected-apps)
The Connected Apps tab allows you to configure personal connections to Slack and project management tools such as GitHub. These connections enable Honeybadger to create and manage issues as your user account on the platforms you connect.
### GitHub sign in
[Section titled “GitHub sign in”](#github-sign-in)
To be able to sign in with GitHub, you’ll need to connect your Honeybadger and GitHub accounts. To do this:
1. Log in to Honeybadger
2. Go to the [User Settings](https://app.honeybadger.io/users/edit) page
3. Click on “Connect your GitHub Account”
4. Tell GitHub to allow Honeybadger to use your account for sign in
> Note that this only sets up GitHub login. It doesn’t connect your projects to GitHub. You’ll have to do that in project settings.
## Cancel user
[Section titled “Cancel user”](#cancel-user)
You are immediately removed from all accounts, teams, and projects when you cancel your user account. Your user info will be deleted, and all accounts for which you are the only owner will also be immediately deleted. This action cannot be undone.
# Event types
> Index of every Insights event type captured by Honeybadger clients.
Every Insights event type emitted by Honeybadger’s client libraries and the platform itself, grouped by what kind of activity the event represents. Select an event type to see its full field schema, emitter, and example queries.
Filter event types…
Showing **116** of **116** event types across **8** clients
## Cache
19Active Support · Cache · Action Controller
| Event type | Client | Description |
| ------------------------------------------------------------------------------------------------------------- | ------- | --------------------------------------- |
| [cache\_cleanup.active\_support](/insights/event-types/ruby/cache_cleanup.active_support/) | ruby | A Rails cache cleanup. |
| [cache\_decrement.active\_support](/insights/event-types/ruby/cache_decrement.active_support/) | ruby | A Rails cache decrement. |
| [cache\_delete\_multi.active\_support](/insights/event-types/ruby/cache_delete_multi.active_support/) | ruby | A Rails multi-key cache delete. |
| [cache\_delete.active\_support](/insights/event-types/ruby/cache_delete.active_support/) | ruby | A Rails cache delete. |
| [cache\_exist?.active\_support](/insights/event-types/ruby/cache_exist_predicate.active_support/) | ruby | A Rails cache existence check. |
| [cache\_fetch\_hit.active\_support](/insights/event-types/ruby/cache_fetch_hit.active_support/) | ruby | A Rails cache fetch hit. |
| [cache\_generate.active\_support](/insights/event-types/ruby/cache_generate.active_support/) | ruby | A Rails cache generate call. |
| [cache\_increment.active\_support](/insights/event-types/ruby/cache_increment.active_support/) | ruby | A Rails cache increment. |
| [cache\_prune.active\_support](/insights/event-types/ruby/cache_prune.active_support/) | ruby | A Rails cache prune call. |
| [cache\_read\_multi.active\_support](/insights/event-types/ruby/cache_read_multi.active_support/) | ruby | A Rails multi-key cache read. |
| [cache\_read.active\_support](/insights/event-types/ruby/cache_read.active_support/) | ruby | A Rails cache read. |
| [cache\_write\_multi.active\_support](/insights/event-types/ruby/cache_write_multi.active_support/) | ruby | A Rails multi-key cache write. |
| [cache\_write.active\_support](/insights/event-types/ruby/cache_write.active_support/) | ruby | A Rails cache write. |
| [cache.hit](/insights/event-types/laravel/cache.hit/) | laravel | A cache key was found (hit). |
| [cache.miss](/insights/event-types/laravel/cache.miss/) | laravel | A cache key was not found (miss). |
| [exist\_fragment?.action\_controller](/insights/event-types/ruby/exist_fragment_predicate.action_controller/) | ruby | A Rails fragment cache existence check. |
| [expire\_fragment.action\_controller](/insights/event-types/ruby/expire_fragment.action_controller/) | ruby | A Rails fragment cache expire call. |
| [read\_fragment.action\_controller](/insights/event-types/ruby/read_fragment.action_controller/) | ruby | A Rails fragment cache read. |
| [write\_fragment.action\_controller](/insights/event-types/ruby/write_fragment.action_controller/) | ruby | A Rails fragment cache write. |
## Check-ins
1
| Event type | Client | Description |
| -------------------------------------------------------- | ----------- | ----------------------------------------------------------- |
| [check\_in](/insights/event-types/honeybadger/check_in/) | honeybadger | A heartbeat or report from a scheduled job or cron monitor. |
## Database
11Ash · Database · Ecto · Redis · Active Record
| Event type | Client | Description |
| ------------------------------------------------------------------------------------- | ------- | --------------------------------------------------- |
| [ash.action.stop](/insights/event-types/elixir/ash.action.stop/) | elixir | An Ash action span finished. |
| [ash.custom.stop](/insights/event-types/elixir/ash.custom.stop/) | elixir | An Ash custom span finished. |
| [ash.query.stop](/insights/event-types/elixir/ash.query.stop/) | elixir | An Ash query span finished. |
| [db.executed](/insights/event-types/laravel/db.executed/) | laravel | A Laravel database query. |
| [db.query](/insights/event-types/python/db.query/) | python | A database query from the Django ORM or SQLAlchemy. |
| [db.transaction.committed](/insights/event-types/laravel/db.transaction.committed/) | laravel | A database transaction was committed. |
| [db.transaction.rolledback](/insights/event-types/laravel/db.transaction.rolledback/) | laravel | A database transaction was rolled back. |
| [db.transaction.started](/insights/event-types/laravel/db.transaction.started/) | laravel | A database transaction was started. |
| [ecto.query](/insights/event-types/elixir/ecto.query/) | elixir | An Ecto repository ran a database query. |
| [redis.executed](/insights/event-types/laravel/redis.executed/) | laravel | A Redis command was executed. |
| [sql.active\_record](/insights/event-types/ruby/sql.active_record/) | ruby | A SQL query from Rails Active Record. |
## Deploys
1
| Event type | Client | Description |
| --------------------------------------------------- | ----------- | -------------------------------------- |
| [deploy](/insights/event-types/honeybadger/deploy/) | honeybadger | A code deploy reported to Honeybadger. |
## Errors
1
| Event type | Client | Description |
| --------------------------------------------------- | ----------- | ---------------------------------------------------- |
| [notice](/insights/event-types/honeybadger/notice/) | honeybadger | An unhandled error captured by a Honeybadger client. |
## Feature flags
1Flipper
| Event type | Client | Description |
| ----------------------------------------------------------------------------------- | ------ | ----------------------------------------------------------------- |
| [feature\_operation.flipper](/insights/event-types/ruby/feature_operation.flipper/) | ruby | A Flipper feature flag check or mutation recorded by Honeybadger. |
## GraphQL
3Absinthe
| Event type | Client | Description |
| ---------------------------------------------------------------------------------------------------------- | ------ | -------------------------------------------------- |
| [absinthe.execute.operation.exception](/insights/event-types/elixir/absinthe.execute.operation.exception/) | elixir | An Absinthe GraphQL operation raised an exception. |
| [absinthe.execute.operation.stop](/insights/event-types/elixir/absinthe.execute.operation.stop/) | elixir | An Absinthe GraphQL operation finished. |
| [absinthe.resolve.field.stop](/insights/event-types/elixir/absinthe.resolve.field.stop/) | elixir | An Absinthe field resolver finished. |
## HTTP
5Finch · Net::HTTP · HTTP client · Tesla
| Event type | Client | Description |
| -------------------------------------------------------------------------------- | ------- | ---------------------------------------------------- |
| [finch.request.stop](/insights/event-types/elixir/finch.request.stop/) | elixir | A Finch HTTP request finished. |
| [request.net\_http](/insights/event-types/ruby/request.net_http/) | ruby | An outbound HTTP request made with Ruby's Net::HTTP. |
| [response.received](/insights/event-types/laravel/response.received/) | laravel | Laravel's HTTP client received a response. |
| [tesla.request.exception](/insights/event-types/elixir/tesla.request.exception/) | elixir | A Tesla HTTP request raised an exception. |
| [tesla.request.stop](/insights/event-types/elixir/tesla.request.stop/) | elixir | A Tesla HTTP request finished. |
## Jobs
24Celery · Karafka · Active Job · Sidekiq · Queue · Oban
| Event type | Client | Description |
| ----------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------ |
| [celery.task\_finished](/insights/event-types/python/celery.task_finished/) | python | A Celery task finished, whether it succeeded or failed. |
| [consumer.consumed.karafka](/insights/event-types/ruby/consumer.consumed.karafka/) | ruby | A Karafka consumer processed a batch of Kafka messages. |
| [discard.active\_job](/insights/event-types/ruby/discard.active_job/) | ruby | An Active Job job was discarded. |
| [enqueue\_all.active\_job](/insights/event-types/ruby/enqueue_all.active_job/) | ruby | A batch of Active Job jobs was enqueued. |
| [enqueue\_at.active\_job](/insights/event-types/ruby/enqueue_at.active_job/) | ruby | An Active Job job was scheduled to run later. |
| [enqueue\_retry.active\_job](/insights/event-types/ruby/enqueue_retry.active_job/) | ruby | An Active Job job was queued for retry. |
| [enqueue.active\_job](/insights/event-types/ruby/enqueue.active_job/) | ruby | An Active Job job was enqueued. |
| [enqueue.sidekiq](/insights/event-types/ruby/enqueue.sidekiq/) | ruby | A job was enqueued to a Sidekiq queue. |
| [error.occurred.karafka](/insights/event-types/ruby/error.occurred.karafka/) | ruby | A Karafka consumer or the Karafka framework raised an error. |
| [job.processed](/insights/event-types/laravel/job.processed/) | laravel | A Laravel queue job finished processing. |
| [job.queued](/insights/event-types/laravel/job.queued/) | laravel | A Laravel job was pushed onto a queue. |
| [oban.job\_finished](/insights/event-types/python/oban.job_finished/) | python | An Oban job finished, whether it succeeded or failed. |
| [oban.job.exception](/insights/event-types/elixir/oban.job.exception/) | elixir | An Oban job raised an exception or exited. |
| [oban.job.stop](/insights/event-types/elixir/oban.job.stop/) | elixir | An Oban job finished without an error. |
| [oban.leader\_exception](/insights/event-types/python/oban.leader_exception/) | python | Oban's leader election loop raised an exception. |
| [oban.lifeline\_exception](/insights/event-types/python/oban.lifeline_exception/) | python | Oban's lifeline loop, which rescues orphaned executing jobs, raised an exception. |
| [oban.producer\_exception](/insights/event-types/python/oban.producer_exception/) | python | An Oban queue producer raised an exception while fetching or acking jobs. |
| [oban.pruner\_exception](/insights/event-types/python/oban.pruner_exception/) | python | Oban's pruner loop, which deletes old completed jobs, raised an exception. |
| [oban.refresher\_exception](/insights/event-types/python/oban.refresher_exception/) | python | Oban's refresher loop, which refreshes producer records and cleans up stale ones, raised an exception. |
| [oban.scheduler\_exception](/insights/event-types/python/oban.scheduler_exception/) | python | Oban's cron scheduler loop raised an exception while evaluating schedules. |
| [oban.stager\_exception](/insights/event-types/python/oban.stager_exception/) | python | Oban's stager loop, which moves scheduled jobs to available, raised an exception. |
| [perform.active\_job](/insights/event-types/ruby/perform.active_job/) | ruby | An Active Job job ran, whether it succeeded or raised an exception. |
| [perform.sidekiq](/insights/event-types/ruby/perform.sidekiq/) | ruby | A Sidekiq job ran. |
| [retry\_stopped.active\_job](/insights/event-types/ruby/retry_stopped.active_job/) | ruby | An Active Job job stopped retrying after too many failed attempts. |
## LLM
6Active Agent
| Event type | Client | Description |
| ------------------------------------------------------------------------------------ | ------ | ------------------------------------------------ |
| [embed.active\_agent](/insights/event-types/ruby/embed.active_agent/) | ruby | An embedding request made through ActiveAgent. |
| [process.active\_agent](/insights/event-types/ruby/process.active_agent/) | ruby | An ActiveAgent action ran. |
| [prompt.active\_agent](/insights/event-types/ruby/prompt.active_agent/) | ruby | A model prompt request made through ActiveAgent. |
| [stream\_close.active\_agent](/insights/event-types/ruby/stream_close.active_agent/) | ruby | An ActiveAgent streaming response closed. |
| [stream\_open.active\_agent](/insights/event-types/ruby/stream_open.active_agent/) | ruby | An ActiveAgent streaming response opened. |
| [tool\_call.active\_agent](/insights/event-types/ruby/tool_call.active_agent/) | ruby | An ActiveAgent tool call ran. |
## Log
1
| Event type | Client | Description |
| ------------------------------------ | ------ | ----------------------------------------------------------------------------- |
| [log](/insights/event-types/js/log/) | js | A console log message forwarded to Insights when insights.console is enabled. |
## Mail
3Mail · Action Mailer
| Event type | Client | Description |
| --------------------------------------------------------------------------- | ------- | ----------------------------------------- |
| [mail.sending](/insights/event-types/laravel/mail.sending/) | laravel | A mail message is about to be sent. |
| [mail.sent](/insights/event-types/laravel/mail.sent/) | laravel | A mail message was sent. |
| [process.action\_mailer](/insights/event-types/ruby/process.action_mailer/) | ruby | Rails generated an Action Mailer message. |
## Metrics
8Heroku Postgres · Autotuner · Karafka · Puma · Sidekiq · Solid Queue
| Event type | Client | Description |
| ------------------------------------------------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------ |
| [metric.hb](/insights/event-types/ruby/metric.hb/) | ruby | A metric recorded through Honeybadger's instrumentation API and flushed by the metrics registry. |
| [postgres](/insights/event-types/heroku/postgres/) | heroku | A Heroku Postgres log line from a Heroku log drain. |
| [report.autotuner](/insights/event-types/ruby/report.autotuner/) | ruby | A tuning recommendation from the Autotuner gem. |
| [statistics\_emitted.karafka](/insights/event-types/ruby/statistics_emitted.karafka/) | ruby | Kafka broker and consumer statistics from librdkafka. |
| [stats.autotuner](/insights/event-types/ruby/stats.autotuner/) | ruby | Periodic Ruby process memory and object metrics from Autotuner. |
| [stats.puma](/insights/event-types/ruby/stats.puma/) | ruby | A periodic Puma stats snapshot. |
| [stats.sidekiq](/insights/event-types/ruby/stats.sidekiq/) | ruby | Sidekiq cluster statistics from the Honeybadger agent. |
| [stats.solid\_queue](/insights/event-types/ruby/stats.solid_queue/) | ruby | Solid Queue cluster statistics from the Honeybadger agent. |
## Notifications
3Notifications
| Event type | Client | Description |
| --------------------------------------------------------------------------- | ------- | ----------------------------------- |
| [notification.failed](/insights/event-types/laravel/notification.failed/) | laravel | A notification failed to send. |
| [notification.sending](/insights/event-types/laravel/notification.sending/) | laravel | A notification is about to be sent. |
| [notification.sent](/insights/event-types/laravel/notification.sent/) | laravel | A notification was sent. |
## Request
18ASGI · Django · Flask · Action Controller · Phoenix · Phoenix LiveView · Routing · Heroku Router
| Event type | Client | Description |
| -------------------------------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------------- |
| [asgi.request](/insights/event-types/python/asgi.request/) | python | An ASGI app finished handling an HTTP request. |
| [django.request](/insights/event-types/python/django.request/) | python | A Django view finished handling an HTTP request. |
| [flask.request](/insights/event-types/python/flask.request/) | python | A Flask route finished handling an HTTP request. |
| [halted\_callback.action\_controller](/insights/event-types/ruby/halted_callback.action_controller/) | ruby | A before/around filter halted the Rails request processing chain. |
| [phoenix.endpoint.stop](/insights/event-types/elixir/phoenix.endpoint.stop/) | elixir | A Phoenix or Plug request finished. |
| [phoenix.live\_component.handle\_event.stop](/insights/event-types/elixir/phoenix.live_component.handle_event.stop/) | elixir | A Phoenix LiveComponent handled a client event. |
| [phoenix.live\_component.update.stop](/insights/event-types/elixir/phoenix.live_component.update.stop/) | elixir | A Phoenix LiveComponent updated. |
| [phoenix.live\_view.handle\_event.stop](/insights/event-types/elixir/phoenix.live_view.handle_event.stop/) | elixir | A Phoenix LiveView handled a client event such as phx-click. |
| [phoenix.live\_view.handle\_params.stop](/insights/event-types/elixir/phoenix.live_view.handle_params.stop/) | elixir | A Phoenix LiveView handled URL params from a navigate or patch. |
| [phoenix.live\_view.mount.stop](/insights/event-types/elixir/phoenix.live_view.mount.stop/) | elixir | A Phoenix LiveView mounted for a client connection. |
| [process\_action.action\_controller](/insights/event-types/ruby/process_action.action_controller/) | ruby | A Rails controller action finished handling an HTTP request. |
| [redirect\_to.action\_controller](/insights/event-types/ruby/redirect_to.action_controller/) | ruby | A Rails controller issued a redirect. |
| [request.handled](/insights/event-types/js/request.handled/) | js | An inbound HTTP request finished. |
| [request.handled](/insights/event-types/laravel/request.handled/) | laravel | A Laravel controller handled an HTTP request. |
| [route.matched](/insights/event-types/laravel/route.matched/) | laravel | Laravel matched a route before running the controller. |
| [router](/insights/event-types/heroku/router/) | heroku | A Heroku router log line from a Heroku log drain. |
| [send\_file.action\_controller](/insights/event-types/ruby/send_file.action_controller/) | ruby | A Rails controller started sending a file. |
| [unpermitted\_parameters.action\_controller](/insights/event-types/ruby/unpermitted_parameters.action_controller/) | ruby | Rails strong parameters filtered out unpermitted keys. |
## Storage
2Active Storage
| Event type | Client | Description |
| ------------------------------------------------------------------------------------------------ | ------ | -------------------------------- |
| [service\_download.active\_storage](/insights/event-types/ruby/service_download.active_storage/) | ruby | A Rails Active Storage download. |
| [service\_upload.active\_storage](/insights/event-types/ruby/service_upload.active_storage/) | ruby | A Rails Active Storage upload. |
## System
4
| Event type | Client | Description |
| -------------------------------------------------------------------------- | ------ | ------------------------------------------------------------------------------- |
| [report.system](/insights/event-types/ruby/report.system/) | ruby | A periodic memory and load average snapshot from the Honeybadger system plugin. |
| [report.system.cpu](/insights/event-types/system/report.system.cpu/) | system | CPU and load average metrics from the Honeybadger CLI agent. |
| [report.system.disk](/insights/event-types/system/report.system.disk/) | system | Disk partition usage metrics from the Honeybadger CLI agent. |
| [report.system.memory](/insights/event-types/system/report.system.memory/) | system | Virtual memory metrics from the Honeybadger CLI agent. |
## Uptime
1
| Event type | Client | Description |
| ----------------------------------------------- | ----------- | ------------------------------------------------------- |
| [site](/insights/event-types/honeybadger/site/) | honeybadger | A snapshot of an uptime-monitored site's configuration. |
## View
4Action View · Blade
| Event type | Client | Description |
| -------------------------------------------------------------------------------------------- | ------- | -------------------------- |
| [render\_collection.action\_view](/insights/event-types/ruby/render_collection.action_view/) | ruby | A Rails view render. |
| [render\_partial.action\_view](/insights/event-types/ruby/render_partial.action_view/) | ruby | A Rails view render. |
| [render\_template.action\_view](/insights/event-types/ruby/render_template.action_view/) | ruby | A Rails view render. |
| [view.rendered](/insights/event-types/laravel/view.rendered/) | laravel | A Blade view was rendered. |
# Elixir event reference
> Insights event types emitted by Elixir.
Every event the Honeybadger Elixir package sends to Insights when instrumentation is enabled: Phoenix requests and LiveView lifecycles, Ecto queries, Oban jobs, Absinthe GraphQL operations, Ash actions, and Finch and Tesla HTTP client requests. Each entry lists the event's fields with their types, and links to its raw JSON Schema.
**18** events emitted by [`honeybadger-elixir`](/lib/elixir/).
***
## Absinthe
### absinthe.execute.operation.exception[](/insights/event-types/elixir/absinthe.execute.operation.exception/ "View event details")[](/insights/event-types/elixir/absinthe.execute.operation.exception.schema.json "View JSON Schema")
An Absinthe GraphQL operation raised an exception. Uses the same fields as absinthe.execute.operation.stop.
| Field | Type | Description |
| ---------------- | -------------- | --------------------------------------------------------- |
| `event_type` | string | Allowed value: `absinthe.execute.operation.exception`. |
| `operation_name` | string | Named operation from the GraphQL query, if present. |
| `operation_type` | string | Operation type: "query", "mutation", or "subscription". |
| `selections` | array\ | Top-level field names selected in the operation. |
| `schema` | string | Absinthe schema module name. |
| `errors` | array\