Skip to main content
Sitepulse tells your team when something needs attention - when an issue opens, when it’s still going (escalation), and when it clears.

​
Where alerts go

Owners and admins choose where alerts are sent. You can set up as many destinations as you like, across any of these channels: Each configuration:
  • Subscribes to Issue detected and/or Issue resolved events
  • Applies to all check tools or only specific tools (Status, SSL, DNS, Broken Links, Performance)
  • Can be enabled, disabled, and tested independently
Because each one stands on its own, you can send different tools or environments to different places - say, critical outages to a paged on-call channel and everything else to email. These settings decide where alerts go. When an issue opens in the first place is up to your monitoring settings.

​
When notifications are sent

​
Issue lifecycle notifications

When automatic monitoring opens an issue or marks one resolved, Sitepulse sends notifications to all enabled destinations that subscribe to the matching event and tool scope.
Exact trigger rules are defined in your team’s monitoring settings (thresholds, confirmation retries, follow-up timing). See Managing issues for how issues relate to notifications.

​
Issue escalation

When escalation is enabled, Sitepulse schedules follow-up reminders at the intervals you select (15 minutes through daily). Escalation reminders are delivered to notification configurations subscribed to Issue detected. No separate channel setup is required. Reminders stop when the issue is resolved or is no longer in an active state (open or acknowledged). Quiet time suppresses escalation the same way it suppresses initial issue alerts.

​
Notification channels

​
Email

Add email addresses that receive issue alerts. Each email notification typically includes:
  • Summary of what was detected
  • Severity (critical / warning / info)
  • The affected site
  • Key details from the check result

​
Slack

Slack app - an OAuth connection: authorize the Sitepulse app and pick a channel. No webhook URL is required. Slack webhook - a Slack incoming webhook URL, if you prefer webhook-based delivery.

​
Discord

Authorize the Sitepulse Discord integration and choose a channel. Sitepulse stores the incoming webhook returned by Discord and formats issue alerts as Discord embeds.

​
Microsoft Teams

A Microsoft Teams incoming webhook URL. Sitepulse formats messages for Teams workflow webhooks.

​
Generic webhook

A URL of your own that Sitepulse calls whenever an issue opens, escalates, or resolves. Use this for your own automation or third-party integrations.

​
Testing a destination

Any webhook-based destination has a Test button. It sends a sample message so you can confirm alerts actually arrive and look right - it’s a connectivity check, not a real issue alert.

​
How secret URLs are stored

Webhook URLs often embed a secret token - Slack incoming webhooks, Microsoft Teams workflow URLs, and your own signed endpoints all do. Sitepulse protects these:
  • Encrypted at rest - the destination is encrypted in the database, not just on disk. Anyone with raw database access still can’t read it.
  • Masked in the dashboard - after you save, the URL is shown masked (the host plus the last few characters, e.g. https://hooks.slack.com/****wXyz). The full secret is never sent back to your browser.
  • Editing keeps the secret - when you edit a saved configuration, the Destination field starts empty. Leave it blank to keep the current URL, or enter a new URL to replace it.
Email addresses are shown in full (they aren’t secrets), and connected Slack and Discord integrations show “Connected” instead of a URL.

​
Quiet time

Quiet time suppresses outbound notifications during a daily window. Use it for overnight periods or planned maintenance. Checks continue to run during quiet time - only outbound notifications are suppressed. Issues can still open, acknowledge, and resolve.