See which epics are at risk because of work they wait on in other teams

Inside a plan, on Jira Premium, once someone has set the plan up. Blockline works on install, without Premium and without a plan: it reads the links your teams already create, judges every epic against seven rules and says why each one is at risk.

The built-in Blocks link type, out of the box: “A blocks B” means B waits on A. If your teams use another link type, such as “depends on”, a Jira admin can add it in Blockline settings and say which way it reads.

Yes. An epic waits on everything its stories and subtasks wait on outside the epic, so a late blocker two levels down still turns the epic At risk, and the reason names the story it came through: “Blocked by PAYC-3 via STOR-4”. Links between two stories of the same epic are internal and do not count against it.

The first of these that has a value: the due date, Target end (on sites with Plans), the end of the active or next sprint the issue is in, the release date of its earliest fix version, and, for a parent with none of those, its latest child’s date. Admins can reorder or switch them off. The source is always written next to the date: “14 Nov (sprint end)”.

Yes, and in company-managed spaces alike. Blockline finds epics and their children by hierarchy level, never by issue type name, and finds the sprint and Target end fields by their type, never by their name, so renamed types and fields make no difference.

Blockline reads Jira as you. If you cannot open an issue, Jira leaves the link to it out of what it shows you, and so does Blockline. Ask its owner for access, or ask someone who can see both issues.

Every view says how old it is (“Updated 3 min ago”) and has a Refresh button. Results are kept for up to 10 minutes per person and view, so the next open is quick; Refresh rebuilds at once.

No. Blockline only reads. Its one Jira permission is read access to issues and their links; the other is storage for its own settings and cache. It cannot edit an issue, a link or a field.

Yes. Every Jira read is made as the person viewing, so Jira applies that person’s own permissions and nobody is shown an issue they could not open themselves. The cache is kept per person, so one person’s view is never shown to another.

In Forge storage hosted by Atlassian: the site’s settings, each person’s saved scope, and each person’s computed views, which are replaced on every rebuild and served for at most 10 minutes. Nothing is sent anywhere else.

Under Jira settings › Apps › Blockline settings, for the whole site: which link types mean “waits on” and which way they read, the order of the date sources, the stalled and idle thresholds, which hierarchy levels are deliverables (rows on the risk board), and a default scope for the Apps page.

No. Epics are the deliverables by default, and everything works on Standard. On sites with a level above epic, such as initiatives on Premium, an admin can make those rows on the risk board too.

Yes. A view judges up to 5,000 issues at once, counting children and linked issues. Past that it says so and shows no numbers rather than partial ones: narrow the scope to fewer spaces, a filter or JQL.

Blockline is free for sites with up to 10 Jira users, with every feature. Above that it is $1.25 per user a month, billed by Atlassian, after a 30-day free trial.

Yes. Above 100 users the per-user rate steps down through Atlassian’s volume tiers.