Scan schedules, and what "due" actually means
Scheduled scanning is the default posture: connect a project once and it is re-checked indefinitely without anybody remembering. The interval follows your plan, the interval you configure per project expresses intent, and forcing an immediate scan is always available when waiting is the wrong answer.
Interval by plan
Free scans one project daily and sends email alerts. Indie scans up to three projects hourly and adds Slack. Team scans up to fifteen projects every fifteen minutes with Discord and custom webhooks. Growth is quoted individually above that. Rates live on the pricing page; what matters here is that findings, remediation SQL and the rule set are identical across plans, and only cadence and alert destinations differ.
What due means
A project becomes due when the time since its last completed scan reaches the effective interval, which is whichever is slower of your project setting and the plan floor: a project configured to poll every five minutes on Indie is scanned hourly. Due therefore means overdue relative to the effective interval, not merely older than you hoped.
Your setting is kept rather than overwritten, so a faster setting takes effect again the moment the plan allows it. Due-ness is evaluated idempotently and is safe to run on several workers at once, so schedulers racing produce one job, not several.
Scan now, and missed runs
The Scan-now button queues a run immediately, whatever the schedule says, and progress streams to the open page. It bypasses only the wait, not the machinery: the same engine runs, the same records are written, and history makes no distinction you would notice between scheduled and forced runs. Retried scans are idempotent, so a rerun emits no transition that was already recorded and forces no duplicate alert.
If the worker is unavailable through a scheduled tick, nothing is lost: due-ness derives from the last completed scan rather than a calendar slot, so the project simply becomes due again as soon as polling resumes.
Missed runs and plan changes
If the worker is unavailable through a scheduled tick, nothing is lost: due-ness derives from the last completed scan rather than a calendar slot, so the project simply becomes due again as soon as polling resumes. Upgrading shortens the interval from the next evaluation onward, and downgrading lengthens it without touching your per-project settings, which survive intact either way.
Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.