Skip to main content
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 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 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 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:

​
Status thresholds

Status rules control when uptime incidents open and resolve: 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: 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

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. 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
Sites can override ignore paths 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 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.

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 and threshold overrides