Webhook
Team Business EnterpriseHoneybadger 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.
1. Select the Webhook integration
Section titled “1. Select the Webhook integration”

2. Set the URL for your webhook
Section titled “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:
{ "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.
3. Set a bearer token (optional)
Section titled “3. Set a bearer token (optional)”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-tokenLeave 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”That’s it! Hit save and you’re good to go.
Payload structure
Section titled “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”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