Risk Signals Reference
Radar monitors signals across six categories. Each signal has a severity tier — advisory, warning, or alert — and fires based on deterministic rules against your project’s data. This page explains what each signal detects, why it matters, and what the thresholds are.
Signals feed a Tier 2 LLM assessment that joins them into a narrative. A single flag rarely tells the whole story; the assessment is where patterns across signals are interpreted together.
Tier 1: Hard Rules
These fire immediately when their thresholds are crossed. No baseline, no judgement call.
MAIN_BUILD_BROKEN
Your main branch build has not passed in 7 or more consecutive days.
A persistently red main branch means every new commit lands on top of a broken foundation. Integration debt compounds daily, and by the time the team tries to stabilize for a milestone the delta is no longer a fix — it’s a rebuild.
Threshold: 7 calendar days since the last successful build on main. Binary alert — no warning tier.
COMMIT_STOP
No contributor has committed to any branch for 5 or more business days.
A team that has gone quiet is either blocked, on leave, or the project is effectively paused. Radar uses the project’s country setting to exclude public holidays, so planned breaks don’t trigger false alarms.
Threshold: 5 business days since the most recent commit across all branches.
AGENT_OFFLINE
A TeamCity build agent has been disconnected for more than 24 hours.
An offline agent silently reduces build throughput, which causes longer queues, which causes developers to start skipping CI. Radar catches it at the infrastructure layer before it erodes team behaviour.
Threshold: 24 hours since lastActivityDate for a disconnected agent.
CRASH_RATE_SPIKE
Crash rate has spiked above three times the 30-day baseline.
The classic smoke-before-fire signal. A 3x spike usually means a regression landed recently.
Threshold: A day’s crash count exceeds 3× the rolling 30-day median. Currently scaffolded — activates when the crash collector is connected.
Tier 1: Detection Patterns
These run against rolling windows of daily project snapshots and carry a severity tier that can be tuned per project.
SCOPE_CREEP
Issues are being created faster than they are being closed.
The most reliable predictor of slip. When the creation-to-closure ratio stays above 1.3 for multiple weeks, the ship date is already moving whether the team has noticed or not.
Thresholds: Warning at ratio ≥ 1.3, alert at ≥ 1.8 over a rolling 7-day window. If nothing was closed and more than 5 issues were created in the window, fires alert directly.
FEATURE_SCOPE_CREEP
A specific feature is ballooning even when the overall project looks stable.
Project-level scope can look fine while one feature eats itself. This signal surfaces per feature so producers can make targeted cut decisions before the problem propagates.
Thresholds: Warning when a feature’s issue count grew more than 30% in the last 30 days with 10+ new tickets. Alert at 50% growth with 15+ new tickets. Requires a feature or epic field in the project mapping.
BUILD_FAILURE_RATE
CI is failing too often.
Above 20% failure rate, developers start losing trust in CI and begin batching local changes. Above 35%, they actively stop triggering CI for minor changes. This is the signal that predicts the eventual “can someone just tell me if this change breaks?” crisis.
Thresholds: Warning at 20% failure rate (7-day), alert at 35%.
BUILD_DURATION_CREEP
Builds are taking significantly longer than they used to.
A slowly rising build time is the purest accumulated tech debt signal. If a build goes from 12 minutes to 20 over a month, the team ships 40% less CI-verified work per day without noticing.
Thresholds: Warning at 25% increase in median build duration vs. baseline, alert at 50%. Requires at least 14 days of snapshots.
COMMIT_VELOCITY_DROP
The team is committing significantly less than their own baseline.
Measured against the team’s own history, not an industry average — studios with slower cadences don’t get false alarms. A velocity drop usually signals either a hidden blocker or the team being pulled onto something not yet reflected in the PM tool.
Thresholds: Warning at 30% drop, alert at 50%, measured over a 7-day window vs. the longer baseline. Requires a baseline of at least 5 commits/week.
ZOMBIE_TASKS
Tickets have been sitting in “In Progress” for too long.
A zombie ticket implies the schedule still assumes it’s moving. Once you find zombies, they usually cluster around the same feature or the same contributor. See also STALLED_ACTIVE in Lifecycle Patterns for the more precise version.
Thresholds: Warning at 3 zombies (issues unresolved for 14+ days), alert at 5.
BRANCH_PROLIFERATION
Too many long-lived branches.
Every long-lived branch is a deferred merge conflict. When branches accumulate, the integration cliff the team is building will eat a sprint. Integration avoidance almost always coincides with a rising build failure rate.
Thresholds: Warning at 5 branches with no build in the last 21 days, alert at 8.
CONCENTRATION_RISK
A single contributor holds too much of the critical work.
Key-person risk is the most common, most under-reported bus factor in indie studios. If a single engineer holds half the blocker tickets and gets sick, the project stops.
Thresholds: Warning if any contributor holds 30%+ of unresolved Critical/Blocker tickets, alert at 50%+. Requires at least 3 critical tickets.
Lifecycle Patterns
Rather than looking at state names, Radar classifies every unresolved issue by its activity history and fires flags based on how it has behaved.
Issues are classified as: active (currently in an active state), parked (was active, now isn’t), queued (never been active), stale_queued (queued, unassigned, 30+ days), or scaffolding (never been touched).
STATE_THRASHING
An issue is bouncing repeatedly between active and non-active states.
A ticket that goes In Progress → Blocked → In Progress → Blocked three times in a month is a ticket nobody is actually driving. The state timeline reveals this even when the ticket looks superficially active.
Thresholds: Warning at 3 round-trips in 30 days, alert at 5. Bulk migrations are excluded automatically.
STALLED_ACTIVE
An issue is in an active state but nothing is happening to it.
This is the modern zombie. Unlike ZOMBIE_TASKS, this uses the full activity stream — comments, field changes, anything — which catches tickets that were worked on briefly and then silently abandoned for the actual fire of the week.
Thresholds: Warning at 14 days since last activity, alert at 30 days.
FORGOTTEN_QUEUE
An issue has been sitting in the queue unassigned for too long.
Forgotten queue tickets are usually symptomatic of a triage breakdown, a discipline running under capacity, or a feature owner who has moved on to something else.
Thresholds: Advisory at 30 days unassigned in queue, warning at 60 days.
UNASSIGNED_ACTIVE
An issue is in an active state but has no assignee.
Either someone is working on something that isn’t officially theirs, or nobody is working on it and the state is a lie. Either case needs a producer.
Threshold: Fires immediately on any active issue with no assignee.
UNPRIORITIZED_ACTIVE
Most of what the team is working on has no priority set.
When more than half the active and queued issues have no priority, either triage has broken down or priority is being tracked somewhere else. Radar flags this so a producer can either fix triage or point Radar at where priority actually lives.
Threshold: Fires when 50%+ of active + queued issues have null/none priority. Requires a priority field in the project mapping.
CONTEXT_SWITCHING
A contributor is thrashing across too many issues at once.
This is the CI/PM correlation that’s only possible when both data sources are connected. A contributor’s commits touching 5+ distinct ticket IDs in two weeks, combined with 2+ of their assigned tickets showing state thrashing, is a strong signal of context-switch overload.
Threshold: 5+ distinct issue IDs referenced in commits over 14 days, plus 2+ of those issues showing at least 2 state thrashing round-trips in the same window.
Issue-Level Flags
These are properties of individual tickets computed from their activity history.
CHRONIC_SLIPPAGE
A ticket’s due date or sprint has been changed repeatedly.
Every push to the next sprint feels cheap in isolation. Three pushes later, it’s a feature that has been “next sprint” for two months and nobody has stopped to ask whether it should be cut. Radar surfaces these as cut candidates.
Threshold: 3 or more changes to dueDate or sprint on the same issue.
ASSIGNEE_CHURN
A ticket has had its assignee changed repeatedly.
Three different people have picked it up and put it down. Either the work is mis-scoped, it’s unpleasant, or leadership doesn’t know who should own it. All three are producer problems invisible on a board.
Threshold: 3 or more assignee changes in the activity stream.
BLOCKER_ACCUMULATION
A single ticket is blocking many others.
The classic bottleneck ticket — almost always some foundational piece that was underestimated and is now holding up the rest of the team. Every day it remains blocked, the blast radius grows.
Threshold: 3 or more open issues linked as blocked-by this ticket.
SILENT_BLOCKER
A blocker has been completely silent for a week.
BLOCKER_ACCUMULATION plus inactivity is the acute form. Something blocking three other tickets has had zero activity for seven days — either the assignee is stuck and hasn’t said so, or it has fallen off their radar entirely.
Threshold: BLOCKER_ACCUMULATION fires AND last activity on the issue is more than 7 days ago.
CRASH_LINKED
A ticket is linked to a known crash signature that is still firing.
The gap between “we have a ticket for it” and “the crash is still happening in production” is often a gap nobody is actively watching.
Status: Currently scaffolded — activates when the crash collector is connected.
Contributor Flags
These are evaluated at the individual contributor level and presented in aggregate. Studios see team-level observations, not individual scorecards. Bot accounts are excluded from all contributor analysis.
GOING_DARK
A contributor has been completely silent for 5 or more business days.
Five business days of no commits or comments is something a producer should know about, surfaced as a team observation (“a contributor has been dark for a week”), not as a name.
Threshold: 5 business days since the contributor’s most recent commit or ticket comment.
CRUNCH_PATTERN
A contributor is committing heavily outside work hours.
Crunch doesn’t announce itself in Jira. It shows up in commit timestamps. Catching this early lets studios intervene before it becomes a resignation letter.
Threshold: Off-hours share of commits exceeds 20% over a rolling 14-day window (minimum 5 commits). Off-hours is outside 7am–8pm in the project’s timezone.
BUILD_BREAKER
A contributor’s commits are triggering a disproportionate share of build failures.
At 30% failure attribution, something is almost always wrong with tooling, onboarding, pre-flight checks, or environment configuration — not the contributor. Build breakers are usually symptoms of a systemic gap.
Threshold: 30% failure rate across builds triggered by the contributor, with a minimum of 3 builds.
VELOCITY_DROP
A contributor’s own commit rate has dropped substantially from their own baseline.
Measured against the contributor’s own history, not the team average. Usually correlates with hitting a wall on a specific piece of work.
Threshold: 40% drop in 7-day commit count vs. 30-day baseline. Requires a baseline of at least 2 commits/day to avoid noise on small samples.
CRASH_ATTRIBUTABLE
A contributor’s recent changes correlate with rising crash signatures.
The code-level companion to BUILD_BREAKER — a contributor whose changes map to spiking crash signatures is either working in an area without adequate test coverage, or landing changes without needed context.
Status: Currently scaffolded — activates when the crash collector is connected.
Estimation Drift
Radar compares estimates to actuals on resolved issues and flags systematic over- or under-estimation. Only runs if the project mapping has identified both estimate and duration fields.
ESTIMATION_DRIFT_UNDER
A team or discipline consistently underestimates.
Radar answers “how much should I pad this?” empirically. If a discipline’s median actual-to-estimate ratio is 1.8×, their sprint commits should be treated as 80% oversubscribed.
Threshold: Median (actual duration / estimate) exceeds 1.5× for a discipline or assignee, with a minimum sample of 5 resolved tickets.
ESTIMATION_DRIFT_OVER
A team or discipline consistently overestimates.
Systematic overestimation means the schedule has hidden slack that nobody is using — usually a sign the discipline is padding to protect itself from previous bad experiences.
Threshold: Median (actual duration / estimate) below 0.5×, minimum sample of 5 resolved tickets.
Deadline-Driven Work
DEADLINE_DRIVEN
A contributor or team is doing the majority of their work right before milestones land.
Teams that do 80% of a milestone’s work in its final week ship undertested, under-iterated features. This pattern — Student Syndrome — is also the most reliable predictor of late-milestone quality collapse.
Each resolved ticket gets a normalized activity timeline from 0 (first activity) to 1 (deadline). The median of those normalized timestamps is the ticket’s center of gravity. An evenly-paced ticket sits at 0.5; a ticket rushed at the end sits at 0.8 or above.
Thresholds: Warning when rolling median center of gravity exceeds 0.7 across at least 5 resolved tickets; alert at 0.8. Requires an effective deadline (milestone, due date, or sprint end) in the project mapping.
Thresholds and tuning
All thresholds above are defaults. Any of them can be overridden per project once the project’s workflow profile has been built during onboarding.
Signal thresholds are calibrated against historical slip data. The Tier 2 LLM assessment takes all active signals together and produces a narrative — individual flags are evidence, not verdicts.