Scheduled Scans: The Check You Don't Have to Remember to Run

A site gets scanned right before launch. Security, performance, infrastructure, SEO, everything comes back clean, and the team moves on to the next thing, confident the site is in good shape. Six months and forty deploys later, a new feature quietly introduced a missing security header, a certificate renewed itself into a weaker configuration, and nobody noticed, because nobody went back and ran that same scan again. The site wasn't "secure." It was secure on the one day someone happened to check.

That gap, between a single point-in-time scan and the actual, continuously changing state of a live site, is exactly what Scheduled Scans, a feature built into FlawPilot, exists to close. Instead of a check that happens once and gets forgotten, it's a check that keeps happening on its own.

Three Things You Can Put on a Schedule

FlawPilot's Scheduled Scans isn't limited to one kind of check. It covers the three main scan types FlawPilot runs, each one scoped to what it's actually checking:

Website schedules a quick scan of a single URL, the same kind of check you'd run manually against a specific page, now running automatically on repeat.

Site Health schedules a full crawl, walking every page it can reach on a verified domain and scoring the site as a whole, rather than just the one URL a quick scan targets.

Code schedules a scan against a specific branch of a connected repository, checking the codebase itself rather than the deployed site, catching issues that live in source before they ever reach production.

Each schedule targets exactly one of these, a quick scan of example.com, a full crawl of a verified domain, a code scan against main, so the schedule matches the actual thing you want watched, instead of one generic "scan everything" job trying to cover all three at once.

Setting a Schedule That Fits How Often Things Actually Change

A schedule is built from a few straightforward pieces: how often it repeats (daily or weekly), which day it runs on for a weekly schedule, what time it runs, and a timezone, so a 9:00 AM scan actually means 9:00 AM where your team is, not wherever the server happens to be.

For a website scan, there's an additional layer of control: which areas to actually check. Security, Performance, Infrastructure, and SEO are each independently toggleable, so a schedule can be scoped to just the areas that matter for a given target, a daily security-only check on a payment page, say, without also re-running a full SEO crawl every single day if that's not what the schedule is for.

Why Results Showing Up Passively Matters

A scheduled scan's results land in two places without anyone having to go looking: delivered by email, and recorded in scan history. That matters because the entire point of scheduling a check is removing the requirement that a person remembers to go run it, and a schedule that still requires someone to log in and check for results defeats half of that purpose. The scan runs on its own, and the result finds you, rather than you having to find it.

When a Schedule Stops Working, You're Told, Not Left Guessing

A schedule that silently stops running is arguably worse than no schedule at all, since it creates false confidence: the team believes a site is being checked regularly, when in reality nothing has run in weeks. Scheduled Scans surfaces failure states directly in the schedule list rather than letting them pass unnoticed: a schedule that's failed several runs in a row shows exactly that, flagged with how many consecutive failures have happened, and a schedule that's paused shows why, whether it was paused manually or paused automatically because a connected integration, the repository access a code scan depends on, got disconnected.

That distinction matters specifically for code scans, which depend on an active connection to the repository being scanned. If that connection drops, whether from a revoked token, a changed permission, or a disconnected integration, the schedule doesn't keep failing silently in the background or quietly stop running without explanation, it pauses and says why, so reconnecting the integration is an obvious next step rather than a mystery to debug.

Domain Verification, Because a Scan Target Isn't Something to Guess At

Website and Site Health schedules require a verified domain before they can run. This isn't an arbitrary extra step, it's what keeps a scheduled scan pointed at a site you actually own and control, rather than something that could be set up against an arbitrary URL. Verification happens once per domain, and from then on, any schedule targeting that domain can draw on it directly.

What Setting One Up Actually Looks Like

Creating a schedule starts with picking what to scan: Website, Site Health, or Code, each shown as its own option with its own description right in the setup panel, a quick scan of one URL, a crawl of every page, or a scan of a repository's branch, so the choice is made explicit rather than inferred from other settings. For a Website or Site Health schedule, the next step is selecting a verified domain and, for Website specifically, the exact URL on that domain to target. From there, the Options section is where the four areas, Security, Performance, Infrastructure, and SEO, get toggled on or off, followed by the repeat pattern, day, time, and timezone that make up the "When" section. The whole thing is built to be set up once, in a couple of minutes, and then left alone.

Schedules Are Capped Per Type, Not Shared

Each scan type has its own limit on how many active schedules it supports, Website, Site Health, and Code each track their own count independently, visible directly in the Scheduled Scans list as a simple "used out of available" count for each type. That matters for planning: a team can't accidentally starve their code-scan schedules by setting up too many website schedules, since the two don't compete for the same pool. It also means the practical question isn't "how many schedules can I have," it's "which specific targets, for each scan type, actually warrant a recurring check," since the limit is scoped to encourage deliberate choices per type rather than one shared budget spread thin across everything.

A Realistic Way to Use It

The useful pattern isn't "schedule everything, constantly." It's matching the cadence to how often the thing being checked actually changes and how costly a missed regression would be. A production website with infrequent deploys might only need a weekly full Site Health crawl. A codebase with daily merges to main benefits from a daily code scan, catching a newly introduced issue within a day of it landing rather than whenever someone next thinks to check manually. A page handling payment or login, where a security regression is especially costly, is a reasonable candidate for a tighter, security-scoped daily website scan even if the rest of the site is checked less often.

Final Thoughts

A site isn't secure because it was scanned once and came back clean. It's secure, or not, based on its actual current state, which keeps changing with every deploy, every renewed certificate, every dependency update, whether or not anyone goes back to check. FlawPilot's Scheduled Scans exists for exactly that gap: instead of a one-time snapshot that quietly goes stale, it's a check that keeps running on its own, flags itself clearly the moment it stops working, and puts the result in front of you without requiring anyone to remember to go looking for it.

You'll find it under Scheduled Scans in the FlawPilot sidebar, alongside Quick Scan, Site Health, and Code Scan.