docs

Scheduler

Run a scan on a repeating timer — nightly, hourly, or on a 5-field cron — and catch new attack surface as the target ships it. (Pro)

The Scheduler runs a scan on its own timer instead of by hand — the way to monitor a target over time. Give a job a target and a cadence and it re-scans on schedule, catching new attack surface as the target ships it, without you re-launching anything. A Pro feature.

The Scheduler view listing recurring scan jobs
Recurring scans on a cron or interval, over a fixed flow set or a live filter that picks up new traffic each run.

What a job scans

Every job runs the same active checks as the Scanner, over a set of captured flows you target one of two ways:

A fixed flow list

The exact flows you picked, scanned again every run. Use it to watch a known set of requests for regressions.

A live filter

A flow filter re-evaluated on every run, so any new matching flow captured since the last pass is pulled in automatically.

The filter is the point. Keep proxying and crawling the target between runs — each scheduled scan re-reads the filter and covers the endpoints that showed up since last time, so new surface gets scanned without you touching the job. Findings land in Findings, deduplicated so the same bug on the same host and insertion point is recorded once.

How often it runs

A job's frequency is one of three shapes:

Cron

A standard 5-field cron expression — minute hour day-of-month month day-of-week. */5 * * * * runs every 5 minutes, 0 2 * * * daily at 02:00, 30 4 1 * * at 04:30 on the 1st. An invalid expression is rejected when you save.

Interval

A fixed gap between runs — every 6 hours, every 30 minutes. The interval must be greater than 0.

Once

No timer at all. The job never fires on its own; you launch it by hand with Run now. Use it to keep a scan saved and ready without it running unattended.

Create and control a job

  1. Build the job

    In the Scheduler view, give it a name, pick the target (a flow list or a filter), set the scan config, and choose a frequency. A job is enabled the moment you save it.

  2. Enable or disable it

    The enable toggle controls whether the timer fires. Disable a job to pause its schedule without losing the definition or its history; re-enable it to resume.

  3. Run it on demand

    Run now fires the job immediately, whatever its schedule says — and it does not move the next scheduled run, so your regular cadence keeps going. Works on any job, including a Once job.

  4. Delete it

    Deleting a job removes it and its entire run history.

Run history

Every firing — scheduled or manual — records a run you can read back in the job's detail panel: when it started and finished, how many flows it covered, how many findings it produced, its status (Running, Completed, or Failed), and the error if it failed.

A scheduled fire that matches no flows is skipped — no scan, no run recorded. A run that hits an error on a flow is marked Failed with the reason, and the schedule keeps going, so one bad run never stops the job.

How the timer behaves

A background loop checks every 30 seconds and fires any job whose next run is due. A few behaviours worth knowing:

No double-firing

The next run is advanced before the scan starts, so a scan that runs longer than the 30-second poll can't fire twice. Interval jobs count from the scheduled time, not the actual start, so they never drift.

Project-scoped

A job pinned to a project only fires while that project is active; switching projects effectively pauses the others. A job with no project is workspace-global and always fires.

Capped concurrency

Up to 4 jobs run at once. If more come due together, the rest wait their turn rather than stampeding the target.

You can also create, trigger, and manage jobs over the REST API, or drive them from an AI agent over MCP.

The Scheduler repeats a scan. For a saved fuzzing or access-control attack on a timer, use Campaigns; for event-driven, multi-step logic, use Workflows.

Last updated 2026-06-17.