Scheduled scans and notifications

The most useful scan is the one you didn't have to remember to run. The desktop app can run scans automatically in the background, alert you when something actually changes, and stay quiet otherwise. This page covers those local desktop schedules. Connected sites can separately use hosted schedules while the desktop is unavailable.

This page covers how to set up schedules, what triggers a notification, and what runs when the app window is closed.

How scheduling works

Each environment of a project can run on its own schedule. SiteCMD's scheduler wakes up every minute, checks which schedules are due, and runs them. When the app window is closed, SiteCMD stays in your system tray and the scheduler keeps running. The app must still be running, even when its window is hidden.

A schedule is bound to one environment. If you want production scanned daily and staging weekly, set each environment's card separately.

Setting up a schedule

1. Open Settings → Scanning and select the environment you want to scan.
2. Find the Scheduled scans card and click Set Up Schedule (or Manage Schedule once one exists).
3. Set the frequency to Daily or Weekly (Off turns it back off).
4. Pick a Time for daily, or a Time and Day for weekly.
5. Click Save.

The next scan time appears on the card. To schedule another environment, switch to it and set its card.

What runs

A scheduled scan runs a full Health Web Scan across the environment's configured scope and enables the rendered axe-core accessibility pass. If a source folder is linked to the project, the same Code Scan engine runs in the same execution. Local database inspection remains off for scheduled runs because it requires an explicit per-run choice.

Notifications

After a scheduled scan, SiteCMD compares the unified SiteCMD Score and active critical count before and after the execution. It sends a notification only when:

• Score dropped by 10+ points since the last scan.
• The critical count increased and the score fell. Both conditions must be true.
• The first available baseline has criticals. With no earlier score to compare, any critical triggers the initial warning.

Only a fully completed route set with the same browser and axe coverage as its baseline can trigger a regression notification. A run with a failed route or unavailable browser layer is still recorded, but it does not produce a score-drop alert.

A clean scan (no criticals appeared, score stayed flat or went up) does not notify. SiteCMD doesn't pop alerts to tell you everything's fine.

What the notification contains

The native OS notification identifies the hostname and reports the current SiteCMD Score, tracked issue count, and critical count. Open SiteCMD to inspect the affected findings. Notification-click navigation is not currently part of the cross-platform contract.

What runs when the app is closed

When you close the SiteCMD window, the app does not quit. It hides to the system tray. The tray icon stays visible (top of screen on macOS, near the clock on Windows, system tray on Linux) and the scheduler keeps running.

From the tray icon you can:

• Open SiteCMD - show the main window again
• Open Overview - show the cross-project overview
• Scan Now - show the main window and request a scan
• Quit - fully exit the app (scheduler stops, no more scheduled scans until you launch again)

To exit completely, use the tray menu's Quit option. Closing the window keeps things running.

Power and battery considerations

The scheduler runs every minute to check for due schedules, but it doesn't actually scan that often. The minute-tick is cheap: it reads from the local SQLite database and goes back to sleep. Actual scans only happen when something is due.

On a laptop on battery, expect scheduled scans to consume the same battery as opening a few web pages: small. The scheduler does not prevent the system from sleeping. If your laptop is asleep when a scan is due, it runs once the system wakes back up.

What schedules don't do

• They don't push code changes. The scheduler runs scans. It doesn't deploy or update dependencies.
• Local schedules don't escalate on their own. Desktop notifications stay on this machine unless you set up local webhooks. Connected-site alert policies can separately deliver email or signed webhooks from the hosted service.
• Local schedules don't run in the cloud. They pause while your computer is asleep and resume when it wakes. A connected site's hosted schedule is the explicit option for scans that continue while your computer is unavailable.

Disabling notifications

If you'd rather watch the dashboard yourself, mute SiteCMD's notifications at the OS level (macOS System Settings → Notifications, Windows notification settings, or your Linux desktop's do-not-disturb). Scans keep running; you just won't get pinged. To stop an environment's scans entirely, set its schedule back to Off.