Schedules, policies and notifications

Run scans on a schedule, decide what makes a result pass or fail, and choose where to be told about it.

Scheduled scansPermalink to Scheduled scans

A repository can scan itself daily or weekly at a time you choose. There is one schedule per repository, and saving replaces whatever was there before.

Times are UTC

A schedule is stored in UTC so that no run can be skipped or repeated by a daylight-saving change. The console shows the time in your own zone beside it.

A missed run is not made up later

If a scheduled run cannot start, the schedule moves on to its next slot rather than catching up. Three days of missed runs do not become three scans.

A schedule can be turned off without being deleted. While it is off nothing runs, even though the next slot is still shown.

Outcome	What happened	Does it need you?
Ran	The scheduled scan started as planned.	No
Skipped — already running	A scan for this repository was already in progress.	No
Skipped — not eligible	The repository could not be scanned at that moment.	Yes — check it is still connected
Skipped — unavailable	Scanning was unavailable when the schedule fired.	No — the next run is unaffected
Skipped — quota spent	There was no scan quota left.	Yes — scheduled runs resume once quota is available
Failed	The run could not be started.	Yes

What the last run did.

Where this happens in the console

SchedulesOne row per connected repository.

PoliciesPermalink to Policies

A policy decides whether a scan result passes or fails. It is per repository, and a repository without one simply has its results reported rather than judged.

Rule	What it does
Fail on severity	Fails the scan when a confirmed finding is at or above the level you pick. Choosing high also fails on critical.
Fail on unrankable findings	Fails when a confirmed finding’s severity could not be determined. A finding nobody could rank is not evidence of safety.
Require adequate coverage	Fails when the scan did not actually cover the code. Zero findings from a scan that did not look is not a clean result.

What a policy can require.

Only confirmed findings can fail a policy

Unconfirmed candidates are leads the scan could not substantiate. Failing a build on them teaches people to bypass the gate, which is worse than not having one.

A policy can fail a scan that found nothing

If you require adequate coverage, a scan that barely ran fails even with no findings. That is the rule doing its job: an empty result from a scan that did not look is indistinguishable from a clean repository.

Where this happens in the console

PoliciesOne rule set per repository.

NotificationsPermalink to Notifications

A destination is somewhere this workspace sends news about your scans. An email address needs nothing else set up; Slack, Teams and a plain webhook each need a URL you get from that service.

Event	When it fires
A scan finished	Any scan reaches a result.
A scan could not finish	A scan ends without producing a result.
A scan failed its policy	A policy judged a result and failed it.

What can be sent.

Notifications about proposed fixes will appear here once Relane can produce a fix from a scanned finding. There is no date for that, and nothing is listed above that cannot currently be sent.

Selecting no events means every event

A destination with nothing selected receives all of them. If you want a subset, choose it explicitly.

A destination address is stored encrypted and never shown again — only its host, or the domain of an email address. To change one, add the new destination and remove the old. Each destination shows whether its most recent delivery arrived.

Where this happens in the console

IntegrationsAdd or remove notification destinations.