Webhooks
Route uptime alerts to Slack, Telegram, or your own systems — and receive external events to trigger checks on demand.
Outgoing Webhooks
Push real-time alert notifications from PingSled to any HTTP endpoint. Define which events trigger a delivery — downtime, recovery, latency spikes, or SSL expiry — and format the payload to match your downstream tooling.
Each outgoing webhook is bound to one or more monitors. When a matched event fires, PingSled sends a POST request with a JSON body to your configured URL. Failed deliveries are retried up to 4 times with exponential back-off (30 s, 2 min, 10 min, 30 min) before the webhook is marked degraded.
Slack Integration
Create an Incoming Webhook in your Slack workspace (Apps → Manage Apps → Incoming Webhooks), copy the webhook URL (e.g. https://hooks.slack.com/services/T01ABC/B02DEF/xYz…), and paste it into a new outgoing webhook in PingSled. Enable the Slack formatter toggle to automatically wrap the payload in Slack's Blocks Kit structure with threaded replies for recovery messages.
Telegram Bot
Start a bot via @BotFather, grab the token (e.g. 723456:AAHx…), and set the webhook URL to https://api.telegram.org/bot<TOKEN>/sendMessage. Use the built-in Telegram formatter to deliver MarkdownV2 messages with inline "Acknowledge" and "View Monitor" buttons. The chat ID is added in the webhook's query parameters as ?chat_id=-1001234567890.
Custom Endpoint
Point the webhook URL at your own service — a PagerDuty event endpoint, a Datadog intake URL, or an internal alerting daemon. You can add custom headers (e.g. Authorization: Bearer sk_live_…, X-Team: platform-ops) and choose between raw JSON or a pre-formatted template. Webhook signatures are verified with an HMAC-SHA256 header X-PingSled-Signature using your account secret key.
Incoming Webhooks
Receive HTTP callbacks from external tools to trigger on-demand checks, pause monitors, or inject synthetic events into your dashboards. Every PingSled account gets a dedicated incoming webhook URL per team, such as https://api.pingsled.com/webhooks/incoming/whk_9f8e7d6c5b4a.
Incoming webhooks are useful for CI/CD pipelines — fire a request after a deployment to immediately validate your staging endpoint, or have your incident management system signal PingSled to mute alerts during a scheduled maintenance window.
Trigger an On-Demand Check
Send a POST to your incoming URL with {"action":"check_now","monitor_id":"mon_abc123"}. PingSled will execute a single probe within 15 seconds and return the result in the response body. This is commonly wired into GitHub Actions or GitLab CI after a merge to main.
Pause or Resume Monitors
Use {"action":"pause","monitor_id":"mon_abc123","duration_minutes":60} to temporarily suspend checks during deployments. A subsequent {"action":"resume","monitor_id":"mon_abc123"} restores normal monitoring. Paused monitors appear with a yellow indicator in the dashboard and do not generate alerts.
Inject Synthetic Events
Push {"action":"log_event","monitor_id":"mon_abc123","event_type":"deployment","metadata":{"version":"3.14.2","commit":"a1b2c3d"}} to annotate your timeline. These events show up on the monitor's status chart alongside real uptime data, giving context to any performance shifts.
Payload Structure
Every outgoing webhook delivers a consistent JSON envelope. Below is the schema for a downtime alert fired by an HTTP monitor.
Outgoing Alert Example
{ "webhook_id": "whk_9f8e7d6c5b4a", "event": "monitor.down", "timestamp": "2025-01-15T08:32:11Z", "monitor": { "id": "mon_abc123", "name": "api.example.com — HTTPS", "type": "http", "url": "https://api.example.com/health", "check_interval_seconds": 60 }, "details": { "status_code": 502, "response_time_ms": 12450, "error": "Bad Gateway", "consecutive_failures": 3, "last_ok_timestamp": "2025-01-15T08:29:51Z" }, "team": { "id": "tm_xyz789", "name": "Platform Ops" } }
Event Types
monitor.down — monitor has been unreachable for the configured failure threshold (default: 3 consecutive checks).
monitor.recovery — monitor returned to healthy status after downtime.
monitor.slow — response time exceeded the latency threshold (e.g. > 2000 ms).
monitor.ssl.expiring — SSL certificate expires within the configured warning window (default: 14 days).
monitor.ssl.expired — SSL certificate has expired.
Security & Verification
Each request includes the header X-PingSled-Signature: sha256=<hex>, computed as HMAC-SHA256 over the raw request body using your team's webhook secret. Verify the signature server-side before processing. Secrets are rotated from Settings → Webhooks → Rotate Secret, and old secrets remain valid for 24 hours to prevent delivery gaps.