> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sitepulse.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Monitoring settings
> Configure automatic check cadence, issue thresholds, escalation, quiet time, and team defaults
Monitoring settings are where you decide how often Sitepulse checks your sites and what counts as a problem worth flagging. Owners and admins can change them; members can see them.
Individual [sites](/guide/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.
Presets range from every minute to every week. Your [plan](/guide/billing#plans) sets the **fastest** you can go: 10 minutes on Starter, 5 minutes on Growth, 1 minute on Agency.
Broken-link and performance checks are heavier, so the fastest they'll run is every 12 hours regardless of plan. Any interval that's too fast for your plan or for one of these tools simply won't be selectable.
Each site runs its checks at its own consistent moment within the interval - one site's every-minute status check might always run at second :17, another's at :43. The gap between checks is always exactly one cadence; spreading sites out keeps checks fast and reliable for everyone.
Issue rules
Issue rules are what turn a failing check into an alert. They decide when Sitepulse **opens** an issue, when it considers the problem **resolved**, and when notifications go out. Your team defaults apply everywhere unless a site sets its own.
### Request header
A default HTTP header sent when Status, Broken Links, and Performance checks fetch your sites. Use it when monitored sites require authentication, an allowlist token, or another custom header to respond correctly.
Format: header **name** and **value** (for example `Authorization` and a bearer token).
Sites can [override this header](/guide/sites#site-specific-overrides) individually.
For broken-link checks, Sitepulse sends the header only to URLs on the monitored site's host. It does not send the header to external links found during a crawl.
### Enabled checks
Each tool has one enabled switch. Turning a tool off stops its scheduled checks and prevents that tool from opening or resolving issues. Dashboard on-demand checks remain available when your role, plan, and monthly quota allow them.
Individual sites can inherit this setting or override it from the site's edit page.
### Default thresholds
Every new team starts with these defaults - adjust any of them to taste:
| Tool | Setting | Default |
| ---------------- | ------------------------------ | ------------------------------- |
| **Status** | Failures to open incident | 2 |
| **Status** | Incident status codes | All supported 4xx and 5xx codes |
| **Status** | Resolve after successes | 1 |
| **Status** | Confirmation retry (minutes) | 2 |
| **Status** | Follow-up while open (minutes) | 5 |
| **SSL** | Expiry window (days) | 14 |
| **SSL** | Failures to open | 2 |
| **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 | Off |
| **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 |
| ------------------------------------------ | --------------------------------------------------------------------------------------- |
| **Status codes that count as an incident** | HTTP response codes that count as failed status checks |
| **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 |
To set **Failures to open** quickly, pick a preset - **Instant** (1 failed check), **Aggressive** (2 failed checks), or **Conservative** (3 failed checks) - or choose **Custom** to enter your own number. The confirmation retry, successes to resolve, and follow-up timing are set separately.
By default, every supported `4xx` and `5xx` response counts as a failed status check. You can clear codes that are expected for a site, such as `401` for a protected endpoint. A connection error, timeout, or other request failure always counts as a failed check, even when no response code is selected.
### 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 |
A performance check breaches when **any** configured limit is exceeded. Leave **Max load time** empty to skip load-time evaluation.
The performance page URL must belong to the monitored site's domain. Set it per site when one route, such as a pricing or checkout page, matters more than the homepage.
### 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 |
Sitepulse stores a baseline from each site's first DNS check. To define explicit expected values instead of the first-check baseline, set [DNS expected records per site](/guide/sites#site-specific-overrides).
Sitepulse opens a DNS issue when:
* 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/*` |
Sites can [override ignore paths](/guide/sites#site-specific-overrides) individually.
If broken-link checks return many `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: immediately, 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](/guide/notifications#issue-escalation) 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](/guide/notifications#quiet-time) for how quiet time interacts with each channel.
## Related guides
What the five tools measure and how to read results
Incident triage after thresholds are breached
Where alerts are sent when issues open, escalate, or resolve
Per-site cadence and threshold overrides