Webhooks & Events
Configure event-driven notifications to sync SystemPulse with PagerDuty, Slack, or custom dashboards.
View Event Schema API ReferenceEvent Types
SystemPulse emits discrete, versioned events whenever monitored endpoints or internal services change state. Each event includes a unique `event_id`, a timestamp, and a cryptographic signature.
status_change
Triggered when a monitored endpoint transitions between `healthy`, `degraded`, or `down`. Includes previous and current status, latency delta, and affected region.
incident_created
Fired when automated thresholds breach or manual escalation occurs. Contains incident severity, assigned responder group, and direct link to the incident timeline.
maintenance_window
Dispatched 30 minutes before scheduled downtime begins. Includes expected duration, affected services, and rollback procedures.
Payload Structure
All webhook payloads follow a consistent envelope format. The `data` object contains event-specific fields, while the root object provides routing and verification metadata.
{
"event_id": "evt_8f9a2c4d1e",
"type": "status_change",
"timestamp": "2024-08-15T14:32:00Z",
"source": "systempulse-monitor",
"signature": "sha256=a1b2c3d4e5f6...",
"data": {
"endpoint_id": "ep_us_east_1",
"previous_status": "healthy",
"current_status": "degraded",
"latency_ms": 1450,
"region": "us-east-1",
"check_url": "https://api.example.com/v1/status"
}
}Verify incoming requests by comparing the `X-SystemPulse-Signature` header against your registered webhook secret using HMAC-SHA256.
Retry Logic & Delivery
SystemPulse guarantees at-least-once delivery for all webhook events. Failed deliveries trigger an exponential backoff sequence before final archival.
Backoff Schedule
Initial attempt: immediate. Retry 1: 30s. Retry 2: 2m. Retry 3: 8m. Retry 4: 32m. Retry 5: 2h. Events failing all 5 retries are logged to your dashboard's `Failed Deliveries` tab.
HTTP Requirements