> ## Documentation Index
> Fetch the complete documentation index at: https://docs.borghq.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Scheduled Assessments
> Repeat a Mjolnir assessment on a date you pick, or on a recurring interval
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
Click **Schedule Assessment** on the Runs page.
The **Run configuration** dropdown lists your completed runs, each labelled with its target domain, repository, and date. Whichever you pick, its target, repository, and scan settings are saved with the schedule.
**One time** asks for a date and time. **Recurring** asks for an interval: a number between 1 and 365, and a unit of days, weeks, or months.
Click **Create schedule**. It appears in the Scheduled assessments list straight away, active by default.
A run can only back one active schedule at a time. Creating a second one from the same run is rejected with "An active schedule already exists for this run". Edit or pause the first one instead.
### 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.
| Badge | What happened |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Paused** | The schedule is switched off and has no next run |
| **Skipped overlap** | A run was already in progress for this pentest, so the recurring schedule moved on to its next interval |
| **Deferred active run** | The same clash on a one-time schedule. Rather than lose the assessment, it retries in five minutes |
| **Billing action needed** | The organisation could not start a credit-consuming run. A recurring schedule waits for its next interval; a one-time schedule retries in five minutes. The card's error line carries the specific reason |
| **Creator unavailable** | The person who created the schedule left the organisation or was moved to read-only. The schedule is paused and needs recreating by a current member |
| **Dispatch failed** | The assessment could not be published, most often because an integration has since been disconnected. The schedule retries in five minutes |
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.
Follow an assessment once a schedule starts it