Questions

No. Inside Jira, no servers, read-only. Blockline runs on Atlassian Forge, reads Jira as you and writes nothing back. Nothing is sent anywhere.

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.

Yes. A dependency drawn in Jira Plans is an ordinary work item link, the Blocks type by default, so Blockline reads it like any other, whether the work items are in a plan or not. If your plans use another link type, a Jira admin adds it in Blockline settings.

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.

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.

Blockline is free for sites with up to 10 Jira users, with every feature. Above that it is billed per user by Atlassian, at a rate that falls as the site grows, after a 30-day free trial; the Pricing tab of the app’s Atlassian Marketplace listing gives the exact cost for your site.

Work items that wait on each other, a circular dependency: none of them can finish until someone breaks the loop. It is not Jira’s Blocked status or a flag, which Blockline does not read. A late or stalled blocker makes an epic At risk, and its reason names the blocker: “Blocked by PAYC-3 via STOR-4” is the reason, At risk the level.

No. A wait inside the same space counts too, and so does an epic whose own date has passed. In the team matrix each space is a team, so teams that share one space show there as one.

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 work item is in, the release date of its earliest fix version, and, for a parent with none of those, its latest child’s date, once every open child has one. Admins can reorder or switch them off. The source is always written next to the date: “14 Nov (sprint end)”.

Blockline reads Jira as you. If you cannot open a work item, 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 work items.

Yes, and in company-managed spaces alike. Blockline finds epics and their children by hierarchy level, never by work 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.

Every view says how old it is (“Updated 3 min ago”), and every page and panel has Recalculate beside it; on a dashboard, Jira’s reload icon on the gadget, or the dashboard’s Refresh, recalculates it. Results are kept for up to 10 minutes per person and view, so the next open is quick; Recalculate rebuilds it, unless it was built in the last minute (ten seconds on a work item).

Yes. A view judges up to 5,000 work items at once, counting children and linked work items. A board of spaces reads their open work items and those done in the last 90 days, so a space’s old history does not count. Past the limit it says so and shows no numbers rather than partial ones: narrow the scope to fewer spaces, a filter or JQL.

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

No. Blockline reads Jira as the person viewing, so Jira applies that person’s own permissions and each person sees only the work items they could 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, each person’s computed views, which are replaced on every rebuild, served for at most 10 minutes (to the same person for the rest of the hour while their fresh builds are used up) and deleted after an hour, the site’s field, work type and link type lists, kept for an hour, and each person’s risk history and last visit to each board (work item keys, risk levels and rule names, no summaries or names), deleted 180 days after their last change, and how much of the hour’s Jira requests each person’s fresh views have used (a count and a time), deleted when the hour ends. 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 long-in-progress thresholds, which hierarchy levels are deliverables (rows on the risk board), and a default scope for the Apps page.

Under Apps › Blockline, and in a Blockline tab in every space. Jira keeps the tab under More when the tab bar is full. On a work item, it is the Blockline group in the Details column, with the panel under View app actions. On a dashboard, it is the Blockline gadget, added like any other gadget.

Where to find it, with pictures →

Ask support first: it may already be a setting. If it is another app, tell us. When other teams need it too, we build it.

Request an app →