Webhooks | Event-Driven Notifications
Real-time monitoring for zero-downtime guarantees
Configure Endpoint View Schema DocsOverview
UptimePulse delivers instantaneous HTTP POST requests to your designated endpoints whenever a monitored asset changes state, breaches an alert threshold, or completes a scheduled maintenance window.
Unlike traditional email or SMS alerts, webhooks integrate directly into your incident response pipelines. Connect to Slack, PagerDuty, Datadog, or custom internal dashboards. Each endpoint supports up to 50 concurrent deliveries, with automatic queue management handled by our global edge network. Simply paste your HTTPS URL in the project settings, and UptimePulse begins pushing events within milliseconds of detection.
Payload Structure
Every webhook delivery contains a standardized JSON envelope designed for predictable parsing and rapid consumption.
Event Metadata
event_id (UUID v4), timestamp (ISO 8601), and region (e.g., us-east-1) identify the trigger origin and exact detection time.
Asset Details
Includes asset_name (e.g., "api.gateway.prod"), check_type (HTTPS, TCP, DNS), and response_code or latency_ms at the moment of failure.
State Transition
Tracks previous_state and current_state values. Example: {"previous_state": "up", "current_state": "degraded"} for response times exceeding 800ms.
Security Signatures
Verify that every incoming notification originates from UptimePulse and has not been tampered with in transit.
We append an HMAC-SHA256 signature to each request using the X-UptimePulse-Signature header. The signature is generated by hashing the raw request body combined with your unique secret key (upwh_sec_8f3a...k29). Your endpoint should reconstruct the hash and perform a constant-time comparison to prevent timing attacks. If the signature mismatch exceeds 5%, UptimePulse automatically flags the endpoint for credential rotation.
Retry Logic
Network blips happen. UptimePulse ensures critical alerts reach your infrastructure through exponential backoff and intelligent circuit breaking.
When your endpoint returns a non-2xx status code or fails to respond within 5 seconds, we queue the event for redelivery. The schedule follows a 1-minute, 5-minute, 15-minute, and 1-hour exponential backoff pattern. After 4 failed attempts, the endpoint enters a 24-hour cooling period to prevent resource exhaustion. You can monitor delivery health via the webhook_deliveries dashboard, which logs HTTP status codes, latency metrics, and exact failure reasons for every attempt.