Protection Status
Protection values combine Sensor observation with the pipeline’s current policy assignment. Observation begins when Team Server receives a build heartbeat.
They do not establish policy mode, violations, blocked outcomes, or uninterrupted Sensor connectivity. Select a pipeline’s protection value to see the live reason, policy, stale window, coverage totals, and selected latest run per build name.
Build Protection
A build is Protected only when the Sensor observed it and its pipeline currently has a policy. Otherwise it is Unprotected.
Observation survives completion. Current assignment means an older observed build can become Protected after policy assignment, or Unprotected after removal. Build age and newer runs do not affect its individual value.
Pipeline Protection
- Group runs by exact stored build name.
- Select each name’s newest run by provider-authored Created time.
- Exclude names whose newest run is outside Days Until Stale.
- Count remaining names whose latest run was observed.
| Value | Conditions |
|---|---|
| Full | Policy assigned; at least one recent name; all latest runs observed |
| Partial | Policy assigned; some, but not all, recent latest runs observed |
| None | No policy, no recent names, or no latest runs observed |
Any policy mode satisfies assignment. An older observed run cannot cover a newer unobserved run with the same name.
Created is upstream creation/start time; Discovered is first storage in Team Server. Late discovery does not make a run newest. When a heartbeat creates the build first, Created temporarily uses heartbeat receipt time until provider synchronization corrects it.
| Provider | Exact build name | Created time |
|---|---|---|
| Bamboo | Job key | Build start |
| GitHub | Workflow name | Workflow creation |
| GitLab | CI job name | Job creation |
| Jenkins | JOB_BASE_NAME, falling back to final JOB_NAME component | Build timestamp |
| Koji | Package, version, optional architecture | Build creation |
| TeamCity | Build configuration name | Build start |
Names are not otherwise normalized or merged. Koji supplies inventory only; its unobserved builds cannot contribute to Full or Partial coverage.
Worked Example
For a GitLab project with a policy and a 14-day stale window:
| Build name | Age | Observed | Included? |
|---|---|---|---|
test | 4 days | Yes | No: replaced by newer run |
test | 1 day | No | Yes: uncovered |
package | 2 days | Yes | Yes: covered |
legacy-scan | 20 days | Yes | No: stale |
One of two included names is covered: Partial. Observing the latest test gives Full; observing neither gives None. The older test and stale scan remain individually Protected because they were observed and a policy is assigned. Removing the policy makes the pipeline None and every build Unprotected.
Settings and Refresh Timing
Under Administration > Pipeline Settings:
| Setting | Default | Range | Effect |
|---|---|---|---|
| Days Until Stale | 14 days | 1–365 days | Recency window for protection |
| Build Discovery Hours | 1 hour | 1–168 hours | Provider query lookback; does not change protection logic or delete stored builds |
Displayed pipeline values use current data. List filters use a stored value refreshed by status_reconcile, every five minutes in production defaults. After builds, assignment changes, or stale boundaries, displayed values and filter membership can briefly differ.
Troubleshoot Unexpected Protection
Check current policy assignment, exact build names, newest Created timestamps, observation, and the stale window. For missing observation, check Sensor connectivity, runner placement, and job-start logs. Check provider synchronization; increase discovery lookback only if needed. Allow reconciliation time for stale list filters.
Use the relevant provider guide for setup checks.