How does the initiative risk radar decide what is at risk?

It lists every open epic, milestone or board initiative that carries a due date and badges each on-track, at-risk or overdue based on days remaining against a configurable horizon. It uses dates only — no sentiment or guesswork.

Why does an initiative not appear on the radar?

Because it has no due date. The widget deliberately only reasons about items with real dates, so undated work is invisible here. A suspiciously short radar usually means missing due dates rather than low risk.

How is this better than a status meeting?

It reports what is genuinely close to its date rather than what feels late. Status meetings systematically over-weight whatever was discussed most recently; the radar does not.

Project risk radar: what's actually slipping, not what feels late

Initiative Risk Radar lists every open epic, milestone, or board initiative that carries a due date, and badges each one on-track, at-risk, or overdue based on days remaining against a configurable horizon. It's a deliberately narrow tool — it doesn't guess at risk from vibes or Slack sentiment. It just does the one thing a status meeting usually gets wrong: tells you what's actually close to the date, using the date.

deckgauge · Board · Intelligence

Mobile Onboarding Revamp
jira · due in 145 daysOn track
Payments Retry Engine
ado · due in 34 daysAt risk
Legacy Auth Migration
jira · due 9 days agoOverdue
Search Relevance V2
github · due in 61 daysAt risk
Notifications Center
jira · due in 210 daysOn track

Open initiatives, badged by days remaining.

What it measures, and where the data comes from

An initiative earns a row here in one of two ways: it's a Jira Epic or a GitHub Milestone with a due date synced in from the source, or it's a board row with a Due date set directly on it — which is how an ADO-backed board, or anything without native epic/milestone support, still shows up. Board rows win: if a board's Due date differs from what's synced, the board date is the one that counts. Done, Closed, and Resolved items drop off the list entirely — this radar only tracks what's still open.

Jira — issues typed Epic with a due date set.
GitHub — repository milestones with a due-on date.
Any board — a Project row with a manual Due date, regardless of which provider it syncs from.

No due date, no radarAn initiative you know is behind but that never shows up here almost always has one problem: nobody set a Due date on it. This widget can't infer urgency from a title or a comment thread — set the date, or the radar stays blind to it.

How to read it

The badge is pure arithmetic, not judgment: overdue is anything with a due date already in the past. At-risk is anything due within the board's configured horizon — 90 days by default, adjustable per board. On-track is everything due further out than that. There's no partial credit and no manual override; move the horizon if 90 days doesn't match how far ahead your organization actually plans.

Read overdue rows as a decision you're late making, not a delivery failure to relitigate. Read the at-risk cluster as your actual worklist for this horizon — that's the set of dates someone needs to actively defend in the next few weeks, not the whole backlog.

What it tells you over time

A radar with the same three items sitting overdue, sprint after sprint, tells you those calls aren't being made — not that the work is impossible, that the decision is being avoided. Watch the at-risk column's size instead of just its members: a horizon that stays thin is a healthy planning cadence; one that keeps swelling, with new items entering faster than old ones clear to on-track or done, is capacity quietly falling behind commitments across the board, not just on one initiative.

Example situations

1. Items sitting overdue, unaddressed

deckgauge · Initiative Risk Radar

Legacy Auth Migration
jira · due 9 days agoOverdue
Data Warehouse Cutover
jira · due 23 days agoOverdue
Checkout Redesign
github · due in 18 daysAt risk

Two initiatives already past their due date.

What you're seeing: two initiatives already past their date, one closing in fast. The overdue ones aren't going to un-slip themselves by staying on the list — every week they sit there is a week nobody made the call on scope or timeline.

How to react: don't let "overdue" quietly become the new normal status for these rows. An overdue badge is a forcing function, not a label — it means someone owes the room a decision this week, not a status update.

Managerial playPut every overdue row on the agenda by name at the next leadership sync, and leave with one of exactly two outcomes: a new date with a real reason, or an explicit scope cut that makes the old date achievable. "Still working on it" isn't a third option — that's how a project stays overdue for a whole quarter. Once a call is made, update the Due date immediately; a stale date on a re-scoped initiative just recreates the same overdue badge next week.

2. A cluster of at-risk items landing in the same window

deckgauge · Initiative Risk Radar

Payments Retry Engine
ado · due in 22 daysAt risk
Search Relevance V2
github · due in 28 daysAt risk
Billing Reconciliation
jira · due in 31 daysAt risk
Partner API v3
jira · due in 25 daysAt risk

Four initiatives, all at-risk, all due within a few weeks of each other.

What you're seeing: four separate initiatives, four separate teams maybe, all badged at-risk within the same few-week window. No single one looks alarming in isolation — that's exactly why this pattern gets missed until it's too late.

How to react: this isn't four independent risks, it's one shared one: whatever capacity finishes these four is about to be asked to finish all of them at once. Treat the cluster as a single planning problem, not four separate status checks.

Managerial playResequence now, while there's still runway — pick which of the four can slip a couple of weeks without real cost, and move its date on purpose instead of letting all four collide and slip by accident. Check for shared dependencies or shared reviewers across the cluster before assuming four teams means four independent paths; a single bottleneck engineer touching three of the four is the more common real story.

Frequently asked

How does the initiative risk radar decide what is at risk?: It lists every open epic, milestone or board initiative that carries a due date and badges each on-track, at-risk or overdue based on days remaining against a configurable horizon. It uses dates only — no sentiment or guesswork.
Why does an initiative not appear on the radar?: Because it has no due date. The widget deliberately only reasons about items with real dates, so undated work is invisible here. A suspiciously short radar usually means missing due dates rather than low risk.
How is this better than a status meeting?: It reports what is genuinely close to its date rather than what feels late. Status meetings systematically over-weight whatever was discussed most recently; the radar does not.

Related widgets

Backlog Age — catches the initiatives that are quietly stalling before they ever reach a due-date crunch.
Iteration Planning Accuracy — a chronic say-do miss is often the mechanism behind a cluster going at-risk together.
Delivery Trend — confirms whether overall throughput can actually absorb what the radar says is coming due.
Back to the widget reference.

Last updated 17 August 2026