Who tells your team when another team's ticket slips?
Quick disclosure: I'm a solo developer and I've built a Jira app for exactly this problem (Tripwire).
I've lost count of the sprint reviews that went like this. A story didn't ship. Not because anyone dropped it, and not because the estimate was wrong. It was blocked on another team's ticket, and at some point that ticket quietly moved from the 12th to the 26th. Nobody on my team knew until we were in the room explaining ourselves.
The frustrating part is that Jira knew the whole time. Somebody changed the due date, Jira wrote it to the changelog with a timestamp and a name, and then told absolutely nobody who was waiting on it.
That's not a bug. Native Jira notifications are built around your issues — the ones you're assigned, reporting, or watching. A cross-team dependency is the opposite shape. The issue that changed belongs to the platform team. The people who need to know are on the payments team, and they have no reason to be watching another team's backlog.
So the one event that should start a conversation produces silence.
Why dependency slips go unnoticed
- The waiting team isn't watching the blocker. Why would they? It's not their work.
- The team that made the change doesn't feel the cost. They moved a date on their own ticket. They're not being careless, they just have no visibility into who's downstream.
- The link exists but nothing reads it. Everyone dutifully sets "is blocked by" and then nothing ever looks at it again.
- A slip isn't just a due date. A ticket punted to the next sprint, or one that's gone quiet for two weeks, hurts you just as much. Nothing flags either.
- Nobody hears the good news either. The blocker gets resolved and the waiting team finds out days later, having already moved on to something else.
How teams handle this today
You can get further than you'd think without buying anything.
Plenty of people just watch the blocking issue manually. This genuinely works, right up until you're waiting on eleven tickets across four teams and your inbox becomes noise you stop reading.
Advanced Roadmaps shows dependency warnings on the timeline, which is useful if you're on Premium and you live in that view. Two conditions a lot of teams don't meet.
There are a good fifteen-plus dependency apps on the Marketplace, and almost all of them are excellent at drawing you a map of what blocks what. A map is genuinely valuable for planning a quarter. The catch is that a map only helps if somebody is looking at it, and the slip happens on a random Tuesday when nobody is.
Jira Automation can absolutely cover a couple of critical dependencies, and if that's your situation you should just do that. It gets awkward at scale — rules are configured per project while dependencies are cross-project by nature, every run eats the same pooled monthly execution quota your other automations need, and the interesting cases ("moved to a later sprint" vs. an earlier one, "this blocker has gone quiet") stop being a rule and start being a project.
And a lot of teams solve it socially, with a recurring cross-team sync or a shared spreadsheet. That works. It also costs you a meeting every week forever.
So what's the question?
The title asks who tells your team when another team's ticket slips. The honest version is two questions:
When a blocker you were waiting on moved last month — who found out, and how long did it take?
If the answer is "the assignee, eventually, by accident" or "we found out at sprint review," that's the gap. It doesn't mean your team is careless. It means nothing in the system is responsible for closing it.
Four principles that fix it, whatever tool you use:
- The dependency has to live on the issues themselves. A "blocks" link in Jira, not a diagram or a page. If it's in a side document it's already stale.
- A change to a blocker has to reach people automatically. Push, not pull. Anything that requires someone to remember to open a view will fail on the week it matters.
- The alert has to go to the waiting side. The assignee and lead of the dependent issue, on the issue, where the work is — not to the team that made the change, who already know.
- It has to be quiet enough that nobody turns it off. This is the one people underestimate. An alerting setup that fires eleven times during sprint planning gets muted within a week, and then you're back to finding out at sprint review.
That last one is also why the wording matters. If an alert reads like an accusation, the team being "reported on" starts resenting it. If it just states what changed and what depends on it, people forward it to each other.
What I built
I built Tripwire to make those four principles the default rather than a discipline you have to maintain.
It watches the "blocks" links you already use. When a blocker slips — due date pushed later, due date removed entirely, punted to the backlog or a later sprint, or just gone quiet past a threshold — it comments on the dependent issue and @mentions its assignee and project lead, in deliberately blame-free wording. When the last blocker resolves it says so too, and it counts remaining blockers first so it never tells you you're clear while you're still stuck.
On the quiet side: one alert per dependency per day, bulk sprint reshuffles fold into a single summary instead of a comment storm, there's a weekly digest, and any project can be muted in one click. There's also a dashboard listing every dependency currently slipped, punted, or stale, which for my teams replaced a standing cross-team status meeting.
It runs entirely on Atlassian Forge, so no data leaves your Atlassian cloud, it uses none of your Jira Automation quota, and it works on every Jira Cloud plan — no Premium or Advanced Roadmaps needed.
How does your team find out when a cross-team blocker slips today? I'm genuinely curious what's worked, especially the low-tech answers — I suspect a lot of teams have a social solution that beats tooling. If you want to look at my approach, Tripwire is live on the Marketplace here: https://marketplace.atlassian.com/apps/709393635/tripwire-dependency-slip-alerts-for-jira
Happy to answer anything in the comments.