Scheduled Scans in Vexta: Cron Jobs and the Scan Queue Explained

Scheduled vulnerability scans are scans that run automatically on a recurring cadence instead of being kicked off by hand every time. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and it handles this with background job execution that supports any cron expression, tracked through a job queue with states you can watch move from queued to running to completed in real time.

How does Vexta run a scan on a schedule?

Scheduling is managed from the dashboard at /schedules, where a scan gets tied to a cron expression rather than a one-off trigger. Because it accepts any standard cron expression, a schedule is not limited to a handful of preset intervals; you can set a full recon-only sweep to run nightly and a deeper vuln scan to run weekly, or match a schedule to a client's change windows.

That matters for a scope that changes shape on its own. A target with a CI pipeline shipping new subdomains and endpoints every week will drift out of date fast if the only scan of it happened once, during the original engagement. A recurring schedule keeps that scan honest without anyone having to remember to trigger it.

What happens to a scan once it is queued?

Every scan, scheduled or manual, moves through the same states: queued, then running, then one of completed, failed or cancelled. Concurrent job support means more than one scan can be in flight at once, which is what makes it practical to run scheduled scans against several targets without them blocking each other in a single-file line.

Progress on a running scan is tracked with real-time WebSocket updates, the same mechanism the dashboard uses to show new findings as they land. That means a scheduled scan that kicks off at 2 a.m. is not a black box you have to check on blind faith the next morning. If it failed, the job state says so, rather than leaving a stale "last scanned" date as the only signal something went wrong.

Why does a job queue matter more than a single background process?

A simple cron entry that just fires off a scan command has no idea whether the previous run is still going, whether it failed silently, or whether five scheduled scans are about to try to hit the same rate-limited target at once. A job queue with explicit states gives you a place to look when something needs troubleshooting, and it is what makes concurrent scheduled and manual scans coexist without stepping on each other.

For a hunter running scheduled recon against several bug bounty programs in parallel, that queue is the difference between glancing at a dashboard to confirm everything ran cleanly overnight, and manually checking log files across a handful of separate scan processes to piece together what happened.

Where scheduling fits for teams and engagements

Scheduled scans are one of the capabilities the Enterprise plan adds on top of the base scanning engine; see the current plan breakdown on the pricing page for what is included at each tier. For a consultancy running recurring assessments as part of an ongoing VAPT engagement rather than a single point-in-time test, that recurring cadence is closer to how a client actually expects coverage to work: not a one-time report, but an assessment that keeps running against a target that keeps changing.

Picture a retainer where the contract calls for continuous coverage rather than one annual test. A nightly recon-only schedule catches new subdomains and endpoints as the client ships, a weekly full scan re-checks everything against the current template set, and a monthly deep scan against the highest-value assets rounds it out. None of that needs a person to remember Tuesday is scan day; the cron schedule and the job queue carry that load, and the dashboard is where you go to confirm it actually happened.

Scheduling around a quiet footprint

A recurring scan against a client's production environment is still traffic hitting their infrastructure on a predictable clock, and Vexta's WAF-aware throttling is what keeps that traffic from tripping alarms it does not need to trip. Pairing that throttling with a schedule set for a client's known low-traffic window, overnight for a customer-facing site, or during a maintenance window for an internal one, is a small piece of planning that keeps a recurring scan from becoming a recurring nuisance for whoever is watching that target's own monitoring.

The same reasoning applies to concurrency. Running several scheduled scans against different targets at the same time is fine because the job queue tracks them independently, but scheduling more than one recurring scan against the same rate-limited target at the same hour just recreates the noisy-burst problem throttling exists to avoid. Staggering schedules by an hour or two across targets that share infrastructure is a cheap way to keep each scan's footprint predictable.

Key takeaways