Individual sites can override cadence, thresholds, and other issue settings. Team defaults apply when a site has no override.
Automatic check cadence
Each check tool (Status, SSL, DNS, Broken Links, Performance) has its own cadence — how often SitePulse runs automatic checks across the team’s sites. Cadence presets range from every minute to every week. Your plan sets the fastest cadence allowed: Starter 30 minutes, Growth 5 minutes, Agency 1 minute. Broken-link and performance checks have an additional 12-hour minimum cadence floor because they are more expensive to run. SitePulse disables cadence options that are faster than your plan or the tool-specific floor. When a site’s enabled checks or cadence overrides change, SitePulse resyncs that site’s automatic schedules.Issue rules
Issue rules define when automatic monitoring opens or resolves issues and sends notifications. Team defaults apply to every site unless a site overrides them.Status check header
A default HTTP header sent with every status check across the team. Use this when monitored sites require authentication or a custom header to respond correctly. Format: header name and value (for exampleAuthorization and a bearer token).
Sites can override this header individually.
Enabled issue tools
Issue opening can be enabled or disabled per check tool. When disabled, automatic checks for that tool still run and save results, but they do not open or resolve issues. Use this to monitor a tool without generating incidents (for example, run performance checks for trends only).Default thresholds
New teams inherit these defaults (from SitePulse configuration):| Tool | Setting | Default |
|---|---|---|
| Status | Failures to open incident | 2 |
| Status | Resolve after successes | 1 |
| Status | Confirmation retry (minutes) | 2 |
| Status | Follow-up while open (minutes) | 5 |
| SSL | Expiry window (days) | 14 |
| Broken links | Minimum broken links | 5 |
| Broken links | Consecutive breaches to open | 1 |
| Broken links | Ignore external links | Off |
| Broken links | Ignore redirects | Off |
| Performance | Minimum score | 50 |
| Performance | Max TTFB (ms) | 4000 |
| Performance | Max load time (seconds) | Not set |
| Performance | Consecutive breaches to open | 2 |
| DNS | Hard failures only | On |
| DNS | Monitored record types | A, AAAA, CNAME, MX, NS, TXT |
| Escalation | Enabled | Off |
Status thresholds
Status rules control when uptime incidents open and resolve:| Setting | Meaning |
|---|---|
| Failures to open | Consecutive failed status checks required before an issue opens |
| Confirmation retry (minutes) | How soon SitePulse reruns a failed check to confirm the failure before opening an issue |
| Successes to resolve | Consecutive successful checks required before the issue is marked recovered |
| Follow-up while open (minutes) | How often SitePulse rechecks an active uptime incident until it recovers |
SSL thresholds
The expiry window (days) controls how many days before certificate expiry SitePulse opens an SSL issue. SitePulse also opens an issue when a certificate is invalid, missing, or cannot be verified, regardless of the expiry window.Performance thresholds
Performance issue rules use three separate breach checks:| Setting | Description |
|---|---|
| Minimum score | Lowest acceptable Lighthouse performance score (1–100) |
| Page URL | Optional URL on the same domain to monitor instead of the site root |
| Max TTFB (ms) | Slowest acceptable time to first byte in milliseconds |
| Max load time (seconds) | Slowest acceptable Time to Interactive (TTI), measured in seconds |
DNS record monitoring
| Setting | Description |
|---|---|
| Hard failures only | Open incidents only when DNS lookups fail with a hard error |
| Monitored record types | Which record types (A, AAAA, CNAME, MX, NS, TXT) are compared for changes on each check |
- A DNS lookup hard fails, or
- Hard failures only is off and a monitored record type is missing or changed from the site’s expected values
Broken-link thresholds and filters
| Setting | Description |
|---|---|
| Minimum broken links | How many broken URLs a crawl must find before it counts as a breach |
| Consecutive breaches to open | How many breached crawls in a row are required before an issue opens |
| Ignore external links | Exclude links whose host differs from the monitored site |
| Ignore redirects | Exclude links that return 301, 302, or 303 |
| Ignore paths | URL path patterns excluded from the crawl; supports wildcards such as /wp-admin/* |
503 responses, the target site may be blocking crawlers. Add SitepulseBot to the site’s robots.txt allowlist.
Escalation
Escalation sends follow-up reminders while an issue stays open or acknowledged. Reminders use the same destinations as Issue detected notifications (email, Slack, Teams, webhooks, in-app). Choose one or more intervals: 15 minutes, 30 minutes, 1 hour, 6 hours, or daily after the issue opens. Escalation is off by default. Escalation does not open new issues. It re-sends alerts on the schedule you choose until the issue is resolved or no longer active. Quiet time suppresses escalation reminders the same way it suppresses other outbound alerts. See Notifications for how escalation interacts with notification configurations.Quiet time
Quiet time suppresses outbound notifications (email, Slack, Teams, webhooks, in-app alerts) during a daily window defined by a start and end time in the team’s timezone. Checks continue to run during quiet time. Issues can still open, acknowledge, and resolve — only alerts are suppressed. See Notifications for how quiet time interacts with each channel.Related guides
Check tools
What the five tools measure and how to read results
Managing issues
Incident triage after thresholds are breached
Notifications
Where alerts are sent when issues open, escalate, or resolve
Managing sites
Per-site cadence, threshold, and snooze overrides