Explore documentation
Webhook subscriptions
Get an HTTP POST request on your endpoint whenever there's a status update on the services you follow.
Subscribe with webhooks
- On the status page you want to follow, click Get updates.
- On the Webhook tab, enter your endpoint URL.
- Enter your e-mail address. It receives the confirmation e-mail and failure notifications.
- To follow only some components, check Subscribe to specific components and select them.
- Click Subscribe, then click Confirm your subscription in the e-mail.
Your webhook starts receiving updates right after confirmation.
Example payloads
Every request shares the same meta and page objects. The event_type field tells you which event was delivered and which event-specific object follows:
Payload structure
Shared objects
Every payload includes meta and page.
Meta
unsubscribe: Link that stops this webhook subscription.documentation: Link to this page.
Page
id: Numeric identifier of the status page.status_indicator: Overall status of the page, one ofoperational,degraded,downtime, ormaintenance.status_description: Human-readable summary ofstatus_indicator.
The status_indicator and status_description values always pair up as follows:
status_indicator |
status_description |
|---|---|
operational |
All services are online |
degraded |
Some services are degraded |
downtime |
Some services are down |
maintenance |
Ongoing maintenance |
Event types
The event_type field determines which event-specific object is present:
incident: New incident or an update to an existing incident.
Payload carries anincidentobject.maintenance: Scheduled maintenance window or an update to one.
Payload carries amaintenanceobject.component_update: Monitored component changed status.
Payload carriescomponent_updateandcomponentobjects.
Incident and maintenance objects
Both objects share the same fields. Maintenance adds starts_at and ends_at, and names its updates array maintenance_updates.
id: Numeric identifier of the incident or maintenance.name: Title shown on the status page.created_at/updated_at: ISO 8601 timestamps.starts_at/ends_at: Scheduled window for maintenance only.shortlink: Public link to the incident on the status page.organization_id: Identifier of the status page the incident belongs to, matchespage.id.incident_updatesormaintenance_updates: Array of updates, newest first. Each entry contains:id: Numeric identifier of the update.status_report_id: Identifier of the parent incident or maintenance.body: Update message text.created_at/updated_at: ISO 8601 timestamps.
Component updates and component objects
The component_update describes the change:
id: Unique identifier for this change event.created_at: ISO 8601 timestamp of the change.old_status: Previous status, set toresolvedwhen the previous status wasn't tracked.new_status: Status the component changed to.component_id: Numeric identifier of the component, matchescomponent.id.
The component describes the component's current state:
id: Numeric identifier of the component.name: Public name of the component.status: Current status, matchingnew_status.created_at: ISO 8601 timestamp of when the component was created.
Component statuses use the same values as page.status_indicator: operational, degraded, downtime, and maintenance.
HTTP request details
Headers
Every webhook request includes these headers:
Content-Type: application/jsonUser-Agent: BetterStack-StatusPage/1.0X-BetterUptime-Event: [event_type]
Event type is eitherincident,maintenance, orcomponent_update.
Request format
All webhooks use HTTP POST with JSON payloads. Requests are sent with:
- UTF-8 encoding
- JSON content type
Timeouts
- Connection timeout: 10 seconds
- Request timeout: 30 seconds
Your endpoint must respond within 30 seconds or the request is considered failed.
Expected response
We consider any 2xx HTTP status code as successful. Your endpoint should:
- Return
200 OK,201 Created, or204 No Content - Respond within 30 seconds
- Not require authentication headers. Use URL-based auth if needed
Redirects
Webhooks do not follow HTTP redirects. Make sure your endpoint URL returns a direct 2xx response.
Retry policy
If your webhook fails, Better Stack retries it up to 10 times with exponential backoff, about 8.5 hours in total.
After failed retries
After 10 failed retries, Better Stack will:
- Deactivate the webhook subscription
- Send an e-mail notification to your contact e-mail about the failure
- Stop sending updates until you reactivate the subscription
Reactivating after failure
To reactivate a deactivated webhook:
- Fix the endpoint issue causing failures.
- Visit the status page and subscribe again with the same endpoint URL.
- Confirm the subscription via e-mail.
Resubscribing with the same URL resets the failure count and requires a fresh e-mail confirmation.
Troubleshooting
Webhook not receiving requests
- Verify the subscription was confirmed via e-mail.
- Check the endpoint URL is correct and reachable.
- Ensure the endpoint returns a 2xx status within 30 seconds.
- Confirm your firewall allows traffic from Better Stack.
- For an
https://endpoint, check its SSL certificate is valid.
Requests timing out
- Move processing to a background queue.
- Return a 2xx response immediately after receiving the payload.
- Check network latency to your endpoint.
Need help?
Please let us know at hello@betterstack.com. We're happy to help! 🙏