Scheduled Assessments

A schedule re-runs a Mjolnir assessment for you, either once at a future date or on a repeating interval. It copies its settings from a run you have already completed, so the target, repository, branch, and scan options stay the same each time. Schedules live on the Runs page, under Security testing > Full pentests > Pentest history. The Schedule Assessment button sits next to Run Assessment in the header, and existing schedules are listed below the stats bar in a Scheduled assessments section.

​

What you need first

• A completed full pentest run. The Schedule Assessment button stays disabled until at least one run has finished, and the tooltip says so. Micro Pentest runs cannot be scheduled.
• A member or admin seat. Read-only members can view schedules but not create, edit, or delete them.
• An active plan. Scheduling is plan-gated. Organisations with a manual Mjolnir grant are allowed through without a plan.

​

Creating a schedule

​

When the first assessment runs

The two schedule types count from different starting points:

• One time runs at the date and time you entered. The dialog rejects anything in the past.
• Recurring waits one full interval before the first assessment. Set it to repeat every month and the first one starts a month from the moment you created the schedule, not immediately. The dialog spells this out under the interval fields.

Editing a recurring schedule’s interval restarts that 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

Creating a schedule takes a snapshot of the source run’s configuration: repository and branch, web target and any extra domains, additional repositories, uploaded documents, model, attack categories, and time limits. Later edits to your Mjolnir setup do not reach an existing schedule, because the snapshot is what runs. To pick up new settings, complete a run with them and schedule that run 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.
• 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 Mjolnir run can be active per pentest at a time, which is why an overlapping occurrence is skipped rather than queued.

​

Time zones

The schedule records the time zone of the browser you created it 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.