Webhook alerts: pipe incidents into your own systems
Email and Telegram are not the only destinations. Webhook contacts let your monitoring events hit an HTTPS endpoint you control so you can transform, route, or log them next to the rest of your ops stack.
When teams choose webhooks
You already run a chat bot, ticket system, or custom on-call router—webhooks avoid copy-pasting incident text between tools.
How contacts work in SitePuls
You define webhook URLs as alert contacts, then assign them to monitors like email or Telegram contacts.
Payload expectations
Your endpoint should accept HTTPS POSTs from SitePuls; validate signatures or secrets in line with your security model.
Retries and failures
Treat webhook delivery like any external dependency: log server-side, alert on repeated failures, and keep timeouts reasonable.
Compared to email
Email is universal; webhooks are programmable—choose webhooks when automation is the goal.
Compared to Telegram
Telegram is a human channel; webhooks are for machines—many teams use both.
What SitePuls does not do
Pre-built connectors for every SaaS—SitePuls gives you webhook endpoints; you wire them to Slack, Jira, or internal APIs.
Next steps
Create a webhook contact under Alert contacts, test delivery, then attach it to high-signal monitors first.
What you can verify with SitePuls here
- Webhook contacts POST JSON payloads to the HTTPS URL stored on the alert contact.
- An optional shared secret can be sent in the X-SitePuls-Token header when you configure it on the contact.
- Contacts choose between a generic JSON schema and a Slack-formatted payload mode in alert contact settings.
Where incident alerts can go
- Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
- Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
- HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
- Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.
Illustrative sample — field names match the product; values are placeholders.
Example: generic webhook JSON body
{
"event_type": "down",
"monitor_id": 123,
"monitor_name": "Example API",
"monitor_type": "http",
"status": "down",
"timestamp": "2026-03-31T12:00:00Z",
"message": "Last check failed (example)",
"incident_id": 456
}Example: Slack incoming-webhook style payload
{
"text": "🔴 *DOWN*\nMonitor: Example API (http)\nTime: 2026-03-31 12:00:00 UTC\nLast check failed (example)\nIncident ID: 456"
}FAQ
Is there a hosted Slack integration?
Use a webhook contact pointed at Slack incoming webhooks or your bridge—SitePuls does not require a separate Slack OAuth app inside SitePuls for basic delivery.
Can I send JSON?
Configure the webhook contact according to what SitePuls sends for incidents—see in-app documentation for payload shape.
Are webhooks encrypted?
Use HTTPS URLs; protect endpoints with auth appropriate for your threat model.
Per-monitor webhooks?
Assign contacts per monitor so routing stays explicit.
Do webhooks replace the incidents UI?
No—incidents still live in SitePuls; webhooks are an outbound copy for other systems.
Rate limits?
Avoid feedback loops: your receiver should respond quickly and idempotently.
Test webhooks without firing a real outage?
Use contact test features in the app where available, or temporarily point to a request bin.
Where is webhook documented?
Alert contacts and monitor assignment are configured in the SitePuls web app after sign-in.