Scheduled Audits

Scheduled audits re-run a full cloud audit of a website on a fixed cadence - daily, weekly, or monthly - with no manual trigger. Each run lands in the dashboard alongside your on-demand audits, so you can track score changes and catch regressions over time.

What each plan can schedule

On the free plan, picking a cadence for a second website asks you to upgrade, and choosing Daily saves as Weekly with a notice. Which website gets the free schedule is your choice: turn the first one off and any other can take the slot. A site that asked for a schedule it cannot have is capped rather than switched off.

A weekly audit spends roughly half the free plan’s monthly credit grant, which is why daily is a paid cadence: four runs a week would exhaust the grant in days.

Setting a schedule

Schedules are managed from the dashboard, per website:

1. Open the website at app.squirrelscan.com.
2. Use the Scheduled Audits card on the website overview (or go to Settings → Schedule).
3. Pick a cadence - Daily, Weekly, Monthly, or Disabled.

Who a schedule belongs to

A schedule belongs to the organization, not to the member who set it up. It keeps running, and each run spends the organization’s credits, after that member is given another role or leaves the organization. Removing a member does not pause the schedules they set up.

To find and stop schedules:

• The website list shows each site’s schedule state. A site’s Settings → Schedule page shows its cadence and next run, and names the member who set the schedule up, or says a former member did.
• Turn a site’s schedule off on that page, or select websites on the list and pick Schedule → Off to turn several off at once.

Owners, admins and editors can change schedules (see roles). When you demote or remove someone, check the schedules on the sites they looked after.

Schedule states

A website’s schedule is in one of five states. The dashboard shows the state on the website list and on the website’s Settings → Schedule page, and the API and MCP tools report the same one.

A capped site keeps what you asked for. Turn another site’s schedule off, or upgrade, and the freed slot goes to a capped site by itself: there is nothing to switch back on. Where several are waiting, the one that has waited longest goes first, and it is re-checked on the way in, so a site whose host stopped resolving while it waited does not take the slot.

When a schedule turns itself on

A newly added website is not scheduled straight away. Recurring audits turn on by themselves once that website has one successful audit, and you are notified in the dashboard when that happens.

Waiting for a real result means a site we cannot reach is never enrolled. A domain that does not resolve, an origin that refuses connections, or a host that blocks the crawler produces a failed first audit, and nothing recurring is started for it.

Two things still apply at that moment:

• Your plan needs a free scheduled-website slot. On the free plan that means your first website; the next one lands in the capped state until you free the slot or upgrade.
• The first scheduled run is at least one full cadence period after that audit. A weekly schedule that turns on today next runs in a week, never the same night.

This applies to websites a CLI audit creates too: a signed-in squirrel audit of a new site adds it to your dashboard and, after its first successful audit, turns recurring audits on. To use the cloud for one audit without that, run it with --ephemeral (or set [cloud] ephemeral = true): the site is not added, no schedule is created now or later. See Ephemeral runs.

You can also switch recurring audits on yourself at any time from the Scheduled Audits card, without waiting for an audit to complete. Turning them off is permanent until you turn them back on: a later audit will not switch them on again.

Where you are told

A schedule that starts by itself is still recurring spend, so every surface that reports a finished audit says the same three things: that the site is re-audited, how often, and where one click stops it.

• The report page in the dashboard carries the notice with a Turn off button.
• The completion email names the cadence and carries a one-click pause link that needs no sign-in.
• The CLI prints one line after a published audit, for an active schedule and for a capped one. See what the CLI prints.
• The digest email for each scheduled run carries the same pause link.

What the CLI prints

squirrel audit --publish and squirrel report --publish each end with at most one line about the audited site’s schedule. Two states have something to say.

An active schedule:

Scheduled audits: <cadence>, and each run costs credits. Turn it off: <schedule-settings-url>

A capped one:

Scheduled audits: this site is not scheduled, your plan schedules <n> website(s). Upgrade: <upgrade-url>

<cadence> and <n> come from the server, so the CLI, the dashboard and the emails cannot describe the same website differently. Where the plan’s allowance is not known, the capped line drops the count and keeps the upgrade link. A capped site with no upgrade link prints nothing rather than half a sentence.

Off, unschedulable and paused print nothing. Neither does a run that published nothing, or one whose server sent no schedule at all.

On squirrel report --publish the line goes to standard error, because that command’s standard output is the report URL on its own and people pipe it.

When a run is skipped for credits

A scheduled run is skipped outright when your balance cannot cover the whole run, not just its base charge. The alternative is worse: the audit would start, spend what was left part-way through the crawl, and publish a report of a site it never finished.

A skipped run is recorded, and the organization is told once with the cost of the run, the balance, and an upgrade link. Recurring audits resume by themselves as soon as the balance covers a run, so there is nothing to switch back on. Before that point, a run that leaves you unable to fund the next one warns you while there is still time to top up.

How runs behave

• Each scheduled run is a normal cloud audit and spends credits like any other cloud audit at its level. Stay within budget with the same per-audit spend controls.
• Scheduled runs use the website’s audit level (or its custom settings), same as an on-demand dashboard audit: they crawl the pages the level asks for, lowered to your plan’s max pages per cloud audit when it asks for more.
• If an audit for the website is already running when the schedule fires, the scheduled run is skipped for that cycle.
• Results, score deltas, new issues, and notifications appear in the dashboard automatically.
• A scheduled run’s real outcome is what the schedule reports, so a failed run shows as failed rather than as a successful dispatch.

The digest email

A completed scheduled run sends a digest to the website’s alert address, so a recurring audit does not run silently. It arrives whatever the run found, including the runs where nothing moved: an email that only shows up on bad news would teach you that no email means nothing ran.

There are five cases where a completed run sends no digest. Email notifications are off for the website, you have switched off Scheduled audit digests in Settings → Email, the account has no usable address, that address has hard bounced or reported a spam complaint, or the comparison against the previous audit could not be completed.

There are three variants, and the subject line tells you which one you have:

Every variant carries the health score, how often the audit runs, a link to the full report, and the pause link below.

The digest replaces the audit completion email for that run, so a scheduled audit never sends both a digest and a completion email. Where a digest is withheld the ordinary audit email covers the run instead: a run that fails sends the failure email, and a run whose comparison could not be built sends the completion email rather than guessing at what changed.

On Pro and Team, a scheduled run that finds links broken since the previous scheduled audit also sends a broken link alert, which lists just those links. It has its own switch under Website → Settings → Alerts, and the website’s email notifications toggle there stops it too.

The digest follows the website’s Settings → Alerts toggle and your account-wide Scheduled audit digests switch in Settings → Email. Turn either off and the schedule keeps running without sending a digest; with the account switch off, a scheduled run sends no completion email in the digest’s place either. A broken link alert follows its own switch and Account alerts instead.

Pausing from the email

Each digest has a pause these audits link that needs no login. Following it opens a confirmation page, and the button on that page stops recurring audits for that one website. The link only ever pauses a schedule, it cannot read your reports or change anything else, and it stops working 90 days after the email was sent.

The confirmation step is deliberate. Mail security scanners and link prefetchers open every link in an email, so following the link alone never pauses anything.

To start the audits again, open the website in the dashboard and pick a cadence under Settings → Schedule. Nothing else about the website changes while it is paused.

When a schedule pauses itself

Two conditions stop a schedule without you asking, so a recurring audit cannot keep spending credits on something that is not working:

• Three audits in a row that failed the same permanent way. A permanent failure is one that will happen again on the next run unless something changes on the site:

  • the domain does not resolve: DNS answers that the name does not exist;
  • the TLS certificate is not valid, for example expired;
  • the start URL redirects somewhere the audit cannot follow, usually off the site, or in a loop;
  • the site refuses the crawler: bot protection or a firewall, or a login wall (HTTP 401 or 403).

  All three failures have to share one of these. A timeout, a server error, a dropped connection, a rate limit (HTTP 429), a DNS lookup that only failed for the moment, a problem on our side, or a failure we cannot place never counts, and neither does a mix of two different permanent failures. A completed or cancelled audit, or any other kind of failure, in between clears the streak. Any audit of the site counts, whether it was scheduled, started from the dashboard, or run from the CLI. Failed audits are refunded, so the failures themselves cost nothing.

• Not enough credits. A run the balance cannot cover is skipped without a charge, and the schedule pauses instead of skipping again every cycle.

Either way you are told once, in the dashboard bell and by email, and a pause after failed audits says what they kept failing on. The email arrives whatever the website’s Settings → Alerts toggle says, because a credit-spending service switching itself off is account news. Only the account-wide Account alerts switch in Settings → Email stops it. It is throttled to roughly one per account in any rolling 24 hours, so several sites pausing around the same time do not each send mail; the rest appear in the dashboard bell. While a schedule is paused no scheduled audit runs, so none fails or emails you.

Fix the cause, then resume the schedule from Settings → Schedule (the email’s Resume recurring audits button opens it). Resuming a schedule that paused after failed audits runs one audit straight away, rather than waiting for the next slot, so you find out at once whether the fix worked. A successful audit clears the streak; if it fails the same way again, the schedule pauses again straight away. Turning recurring audits back on for many websites at once, and resuming a schedule that paused for credits, waits for each site’s next slot as usual.

Audit source

Every audit records where it was triggered from. In the dashboard, audits and reports are tagged with a source badge:

• CLI - run from the squirrel command line
• Cloud - run on demand from the dashboard
• Scheduled - run automatically by a schedule
• GitHub - run from a GitHub pull request or push

This makes it easy to tell an automated weekly run apart from one you kicked off by hand.

Related

• Cloud overview - what cloud features add
• Credits & Pricing - how scheduled runs are billed
• Dashboard - where scheduled results live
• Emails we send - every automatic email and how to stop it