Tell the team that holds you up, before the date slips

The team that is late is usually the last to hear it. Their API slipped a week, which was fine for their own sprint, and two other teams’ epics now miss their dates. On Atlassian Community it reads “will Team Member #2 be notified that his work will be delayed?”, or, from a Champion’s article, links are “invisible until you’re already looking at the item” (Community, August 2026). This page says what Jira can tell the blocking team by itself, then what Blockline shows them.

What Jira does by itself

Each issue lists what it blocks under Linked work items. The team sees it when it opens that issue.
No warning when a date slips. The requests to notify blocked issues (JSWCLOUD-9039) and to warn when a dependency will miss (JSWCLOUD-25384) were closed without a fix.
Automation reacts to events. A rule can run when an issue is linked, or when a field such as the due date changes.

An automation rule

For each blocker, a rule can tell the people waiting:

Trigger: Field value changed, the due date (or Issue transitioned, for status).
Condition: Related issues condition, linked issues of the type “blocks” exist.
Branch: For linked issues, link type “blocks”.
Action: comment on each linked issue, or send an email to its assignee, with the new date.

What it cannot see:

The other end’s date. The rule knows the blocker moved, not whether the waiting issue still makes its date, so it tells everyone every time.
The epic. The link is between stories; the epic that will miss its date is one level up and hears nothing.
What never changes. A blocker never started, with no date, or with nobody on it fires no event at all.

With Blockline

Blockline is our app. It shows the blocking team whom it is making late, and by how much, without anyone sending anything:

Open the space’s Blockline tab. When its work makes other spaces’ deliverables late, a line under the counts says so: “Payments Core (PAYC) is holding up 4 deliverables in other spaces: 1 Blocked, 3 At risk.”
Press Show them. Holding up others lists each one, led by the issue here and whom it is assigned to, then their work and its space, when they need it, and what it does to them: “45 days late”, “Circular”, “Not started”.
On the blocker itself, the panel and the Details column lead with it: “At risk · Makes 2 issues late: MAPP-1 by 45 days (via MAPP-3), STOR-1 by 6 days (via STOR-4)”.
Export CSV on that tab takes the list to the conversation, and Map on a row draws the waiting epic’s chain.

Starting the conversation

The list is the agenda. A few habits make it work:

Look at it before the planning, not after. The blocking team can still move a story into the sprint, or tell the other team the new date while their own plan can change.
Lead with the date, not the blame. “PAYC-3 is due 13 Nov; STOR-1 needs it by 7 Nov” is a question both teams can answer.
Fix the data first. A blocker with no date or nobody on it shows as Watch, not late. The Data health tab lists those, and an hour of dating and assigning makes the list honest.
Close what is done. A blocker finished in reality but open in Jira keeps another team waiting on paper.

The waiting team sees the same dependency from its side, on its epic (Find the epics blocked by another team). Nothing is sent and nothing is written to Jira: Blockline only reads, as each person looking (Permissions and data). More on the Blockline home page.