Scheduled Assessments

A scheduled assessment re-runs a pentest for you on a repeating interval. Scheduling is not self-serve: you can’t create a schedule in Odin, and the team sets recurring assessments up on request. Until agentic whitebox is enabled, Contact the team about pentesting opens Live Support in Odin with a message ready to send; after that, use Live Support in the Odin sidebar.

​

Recurring assessments set up by the team

A recurring assessment keeps the repository, branch, and the folders to test or leave out that you agreed with the team. A run only starts while your organisation is active and, where your contract uses credits, enough remain. Each run it starts appears in the run list on the Agentic whitebox page like any other pentest, and its findings land in Findings. These schedules are not listed in Odin. To change or stop one, contact the team the same way.

​

Earlier schedules

Schedules created in Odin before scheduling moved to the team keep running. They are listed above the run history on the Agentic whitebox page, under Testing > Pentest, in a Scheduled assessments section that only appears while your organisation has at least one. You can pause, edit, or delete them, but not create new ones. Read-only members can view them but not change them.

​

When the next assessment runs

• One time runs at the date and time set on it. Moving it to a time in the past is rejected.
• Recurring runs once every interval.

Editing a recurring schedule’s interval restarts the count: the next assessment moves to one fresh interval from when you saved the change. Monthly intervals use calendar months and clamp to the end of a short month, so a schedule anchored on 31 January next runs on 28 February.

​

What the schedule saves

Each of these schedules holds a snapshot of the configuration of the run it was created from: repository and branch, web target and any extra domains, additional repositories, uploaded documents, model, attack categories, and time limits. Later edits to your pentest setup do not reach an existing schedule, because the snapshot is what runs. To run on a schedule with new settings, ask the team for a recurring assessment instead. Repository credentials are the exception. GitHub installation tokens and Azure DevOps access tokens expire long before the next assessment is due, so a fresh one is minted at dispatch. If the underlying integration has been disconnected in the meantime, the dispatch fails and the schedule shows an error.

​

Managing a schedule

Each card in the Scheduled assessments list shows the target and repository, whether it runs once or on an interval, its next and last run times, and its time zone. Three controls sit on the right:

• The switch pauses and resumes the schedule. A paused schedule keeps its settings but has no next run; resuming a recurring one sets the next assessment a full interval ahead. A run can only back one active schedule, so resuming is rejected with “An active schedule already exists for this run” while another schedule from the same run is active.
• The pencil opens Customise schedule, where you can move a one-time schedule’s date or change a recurring one’s interval. The source run cannot be swapped.
• The bin deletes the schedule after a confirmation. Completed runs and their findings are not affected.

​

Status badges

A badge appears on the card when the last attempt did not start an assessment. Only one pentest run can be active per pentest at a time, which is why an overlapping occurrence is skipped rather than queued.

​

Time zones

Each schedule records the time zone of the browser it was created in, and the list formats its next and last run times in that zone. Editing from a different zone is fine. The dialog shows times in your current zone and names the zone the schedule was created in, so you can compare the two before saving.