Skip to content

Webhook

Team Business Enterprise
View Markdown

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.

webhook integration webhook form

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:

{
"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 for all available events and their structure.

Every webhook we send already includes a Honeybadger-Token header 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:

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.

That’s it! Hit save and you’re good to go.

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)

The following events are supported by the Webhook integration:

Sent when an error is assigned to a user.

Top-level properties: event, message, actor, fault, assignee

Sent when an SSL certificate is about to expire.

Top-level properties: event, message, project, site

Sent when an expected check-in is missing.

Top-level properties: event, message, project, check_in

Sent when a check-in reports successfully.

Top-level properties: event, message, project, check_in

Sent when a comment is added to an error.

Top-level properties: event, message, actor, fault, comment

Sent when a deployment is recorded.

Top-level properties: event, message, project, deploy

Sent when an uptime check fails.

Top-level properties: event, message, project, site, outage

Sent when an error occurs.

Top-level properties: event, message, project, fault, notice

Sent when error rate threshold is exceeded.

Top-level properties: event, message, project, fault

Sent when an error is marked as resolved.

Top-level properties: event, message, project, fault

Sent when a resolved error occurs again.

Top-level properties: event, message, project, fault

Sent when an uptime check succeeds after being down.

Top-level properties: event, message, project, site, outage

Sent when a project’s error volume spikes above its learned baseline.

Top-level properties: event, message, project, volume_spike