Run the scan on a clock, not on a reminder
Daily, weekly or monthly, at a time in your own timezone — and each run is a numbered run of the same scan, so every report arrives with a comparison against the one before it.
Scan a public URL free · no credit card required
- 3 cadences
- daily, weekly or monthly
- Your timezone
- a named zone, not an offset
- Late, never lost
- a missed run stays due
- Exactly once
- no run ever doubles up
Run the scan on a clock, not on a reminder
Set it once. TestKase holds the schedule, runs the scan and compares each report against the previous one.
- Step 1
Pick a cadence
Daily, weekly or monthly. Weekly takes a day of the week; monthly takes a day of the month.
- Step 2
Set the time in your zone
A time in 24-hour form, resolved in a named IANA timezone you pick — so 09:00 stays 09:00 local through the clock change.
- Step 3
Read each run against the last
Every run is a numbered run of the same scan, so each report arrives with a comparison against the one before it.
What keeps a schedule reliable
Four guards on the sweep, plus a plan check that fails loudly instead of silently.
Recovers a missed run
The next run time is held on the scan row, so a deploy, an outage or a restart leaves a run late rather than lost — the next sweep picks it up.
Never doubles up
Advancing the schedule and starting the run are one claimed operation, so several servers noticing the same due scan still fire it exactly once. A scan still running is never given another.
Backlog drains oldest first
After an interruption the most overdue schedules go first and the rest stay due for the next sweep. Nothing is dropped to catch up.
Monthly clamps, never skips
A monthly schedule set for, say, the 30th still runs on the last day of a shorter month instead of being skipped — the failure mode people discover in February and not before.
Reported when late
A due scan is normally claimed within minutes. One that is more than an hour late is reported as a fault on our side rather than left to look like ordinary timing.
Automate entitlement, re-checked
Recurring runs are automation and the entitlement is re-checked every run. A lapsed plan fails the run with a message saying why and keeps the schedule, so it resumes when the plan does.
A schedule that lives in your data, not in a queue
There are two ways to build a recurring job, and only one survives a bad week.
Each firing publishes the next one. Drop a single delivery and that schedule ends — not pauses, ends — because the message that would have re-published it never arrived and nothing is holding a record that a schedule was supposed to exist.
The scan row holds the next run time, and a sweep looks for scans whose time has passed. A missed tick, a deploy, an outage of any length leaves the row exactly as due as it was, so the next sweep picks it up. Lateness is the worst outcome available, and there is one place to look for whether a schedule exists — the scan.
Frequently asked questions
Daily, weekly or monthly, at a time you choose in 24-hour form. Weekly takes a day of the week; monthly takes a day of the month. The time is interpreted in an IANA timezone you pick, so a schedule set for 09:00 in Europe/London stays at 09:00 local through the clock change. There is no hourly option and no arbitrary cron expression.
It still runs. The schedule is a booking held in the scan's own row: the next run time sits in the past until a run actually starts, so the next sweep picks it up. Nothing about the schedule depends on a message being delivered on time. Exact timing is not guaranteed — a due scan is claimed within minutes, not at the second, and after an interruption it can be later, deliberately, because draining a backlog in order beats dropping runs.
It runs on the last day of the month. A monthly schedule clamps to the number of days the month actually has rather than skipping the month, which is the failure mode people discover in February and not before.
No. A scan that is still running is never given another run, and a run that is due while one is in progress waits. That keeps a slow scan from stacking on itself into a queue you did not ask for.
Recurring runs are automation and need an Automate entitlement, and that is re-checked at every run rather than only when you set the schedule. If the plan lapses, the run fails with a message saying why and the schedule stays in place — it resumes when the entitlement does, instead of quietly deleting itself.
It re-runs the URLs you listed; it does not discover new pages between runs, so if the site grew the scan does not grow with it until you say so. It does not notify you when a run introduces issues — the comparison against the previous run is on the report, not an alert. To stop a schedule, disable it (which keeps the configuration to switch back on) or clear it (which removes it); the sweep only picks up schedules that are enabled.
Related
- WCAG 2.2 CoverageWhat automated rules reach, and what is marked not checked
- WCAG 2.2 ChecklistAll 55 A and AA criteria, and which a machine can reach
- European Accessibility ActWho the EAA covers and what it asks for
- All of AccessibilityAutomated WCAG scanning, workflow audits, and reports
- PricingPer-seat test management and per-thread device testing, priced on the page
Set it once and read the difference each week
Scan a URL now, put it on a cadence, and let the second report tell you which way the site moved.