Scans

Scanning is configured entirely on the Scan Configuration page: scope, content selection, engine tuning, and schedule all live together on one screen, so each saved configuration is fully self-contained.

This page is the option-by-option reference. For working with the screen, see Scan Configuration in the user guide.

Scope

Option	Notes
Name	The configuration name.
Projects	All accessible projects, or a comma-separated project key list.

Content

Option	Notes
Included fields	Fields to scan, e.g. summary, description.
Excluded fields	Fields to skip, e.g. environment, labels.
Include comments	Whether issue comments are scanned.
Scan attachment contents	Off by default. Reads the text inside attachments with the same rules. Requires the SCAN_ATTACHMENTS license feature; see Attachment scanning for supported formats and limits.
Text mode	RENDERED, RAW, or both (default). Both is worth keeping: rendered text is what people read, raw values catch secrets hidden inside markup. Both variants arrive in the same Jira call, so covering both costs no extra request - but a match present in both is recorded as two findings, one per variant, because the text variant is part of a finding's source locator.

Scan engine

How hard this configuration works Jira. These settings are saved with the configuration, so every run records exactly what it used.

Option	Default	Notes
Worker count	2	Parallel scan workers.
Max issues per minute	1000	Throughput ceiling, the main lever on Jira load.
Batch size	100	Issues fetched per API call.
Retry attempts	3	Retries for transient Jira and API errors.
Retry backoff seconds	30	Wait between retries.
Allowed scan windows	none	Optional weekly day/time windows in which scans may start.

Choose conservative engine values first. The scanner is designed so that scan duration is secondary to keeping load on your Jira instance safe - and the limit on scan speed is normally Jira, not the scanner.

Allowed scan windows

Windows are the guard rail that keeps scans off your Jira instance at the wrong times. Leave the list empty - the default - and a scan may start whenever it is started. Add one or more windows and a scan may only start inside one of them.

• Both ways of starting are held to the windows, the Start scan button and the schedule alike. A window that only held back the scheduler would be no protection, since anyone could walk past it with the button.
• Only the start is gated. A scan that started inside a window is allowed to run to completion, even if it overruns the end. Nothing is suspended halfway through; use the throughput ceiling above to bound how hard a long run pushes.
• A window whose end is earlier than its start runs past midnight into the following day. Friday 22:00-02:00 covers Friday evening through Saturday morning - overnight maintenance windows are written as one window, not split at midnight.
• The range is half-open: a scan may start exactly at the start time, but no longer at the end time. Times are evaluated in the server's time zone, the same as cron expressions.

Starting a scan by hand outside every window is refused, and the message names the next time a window opens. When a scheduled run comes due outside every window, the tick is skipped rather than postponed - it does not queue up and run late. The skip is recorded as SCAN_SCHEDULE_SKIPPED in the audit log, and the panel reports the last run as skipped.

A schedule that fires outside its own windows will therefore never run. If a configuration keeps reporting skipped runs, check the cron expression against the windows - the two are set independently and it is easy to let them drift apart.

Schedule

Attach a cron expression so the configuration starts scans on its own, instead of someone remembering to press the button.

• A dropdown offers presets - Every night at 03:00, Every weekday at 06:30, Every Sunday at 02:00, First of the month at 04:00, Every 6 hours, and Every hour - and writes the matching expression; editing the field switches it to Custom….
• Expressions use six fields: second minute hour day-of-month month day-of-week, evaluated in the server's time zone. The page previews the next fire times.
• A warning appears if the expression fires more than once a day.
• An expression that is valid but can never fire (for example, February 30th) is rejected at save time rather than silently never running.
• Scheduling is only active while the schedule is switched on.

Scheduled runs never overlap. If a scan of the same configuration is still running when the schedule fires, the tick is skipped and recorded as SCAN_SCHEDULE_SKIPPED in the audit log - it does not queue up behind the running scan. The panel shows the last and next scheduled run, and warns when the most recent attempt was skipped or errored.

Schedules follow the configuration, not one version of it: saving a new version carries the schedule forward. Running several scanner instances against the same database will not double-fire a schedule.

Scope preview

Before saving, the preview estimates the project count, sample project keys, the issue count, and the expected runtime, by asking Jira how many issues the scope actually covers. Check it - a scope of "all accessible projects" is usually larger than people expect.

Immutability

Scan configurations are immutable snapshots: every scan run references the exact configuration version it ran with, including the engine settings in effect, so results stay explainable months later. To change scope or tuning, save a new version. All versions of the same configuration share a config group, which is what the schedule and scan history attach to.

Scan behavior

• Scans are always full scans (no incremental scanning) and strictly read-only.
• Raw field values are processed in memory only and never persisted.
• Running scans can be paused, resumed, and cancelled; failed scans resume from the last checkpoint without duplicating findings.