A schedule repeats a fixed template on an hourly interval so coverage is checked without anyone remembering to click run. This guide creates one from the current form and shows how to verify it does what you expect.
The mental model matters: automation repeats, it does not interpret. A schedule is a disciplined clock, not an analyst.
1. Create the schedule
- Open /runs/schedules, use a name that identifies the target and purpose, and enter a public HTTP or HTTPS asset URL.
- Choose an interval from 1 to 168 hours. The current page creates `every_hours` schedules; daily and weekly cadence types exist in the API contract but are not offered by this form.
- The form creates a fixed staging template with quick scan, low attack depth, and the OWASP tag. Review that scope before relying on the schedule.
Choose an interval from 1 to 168 hours — the current page creates every_hours schedules, with daily and weekly cadence types present in the model but not in this form. The created schedule uses a fixed staging template: quick scan, low attack depth, OWASP tag. Review that scope before relying on it.
2. Check what was scheduled
- After creation, confirm that the list shows the target, scan profile, attack depth, cadence, and next run time you expected.
- Use Pause or Resume to control future triggers and Delete to remove the schedule. The page does not display `last_triggered_at` or a schedule-specific run history.
- Check the general runs list after the expected time and allow for scheduler or worker delay. A queued or completed run is evidence to inspect, not an automatic security conclusion.
After creation, confirm the list shows the target, profile, depth, cadence, and next run time you expected. Pause, Resume, and Delete control future triggers; the page does not show last_triggered_at, so check the runs list after the expected time and allow for scheduler or worker delay.