Tripwire Docs

What Tripwire does

Your team depends on issues owned by other teams. When one of those blockers slips, Jira writes it to the changelog and tells no one — you find out at sprint review. Tripwire fixes that, without a Slack bot and without any data leaving Atlassian.

Tripwire watches the built-in "blocks" issue links you already use. When a blocker slips — its due date moves later, it gets punted out of a sprint, or it goes quiet for too long — Tripwire posts a blame-free comment on the dependent issue and @-mentions the people who need to know. When the blocker resolves, it tells them they're unblocked. It's a focused Forge app for Jira Cloud — one job, done well.

Getting started

After a site admin installs Tripwire from the Atlassian Marketplace, it starts working immediately — there is nothing to configure. You'll interact with it in three places:

How dependencies are detected

Tripwire builds a registry of dependency edges from your issue links. An edge is a directed pair: a blocker (the issue that must be done first) and a dependent (the issue waiting on it). It reads the direction from the link so it always alerts the side that is waiting, never the side doing the work.

• Which links. By default the standard Blocks / is blocked by link type. You can change the watched link types in Settings.
• Cross-project by default. The whole point is cross-team dependencies, so out of the box Tripwire focuses on edges where the blocker and dependent live in different projects. You can widen it to same-project dependencies too.
• Registered silently. Creating a new "blocks" link just starts tracking — there is no "you created a link" notification (event E7). Removing the link stops tracking, also silently (E8).
• Self-healing. A daily reconciliation sweep re-reads your links so a missed real-time event is corrected within a day, deactivated edges are purged after 90 days, and the registry is capped so it never grows without bound.

Alerts — every notification Tripwire can post

Every alert is a comment on the dependent issue, written to be blame-free — it states what changed, never who is at fault. Here is the complete catalogue.

Due-date slip

The blocker's due date moved later by at least your slip threshold.

Due-date removed

The blocker's due date was cleared entirely — often a quiet signal that a commitment has evaporated.

Punt to the backlog

The blocker was pulled out of its sprint back into the backlog — no sprint now owns it.

Punt to a later sprint

The blocker moved from its current sprint to one that starts later. Tripwire reads sprint start dates so it can tell a genuine push-out from routine board hygiene.

Gone quiet (staleness)

An unresolved blocker hasn't been touched — no status, date, or field change — for longer than the stale window (about a week by default). No one moved it; it just went silent.

Unblocked

When a blocker resolves, Tripwire is remaining-blocker aware — it checks whether the dependent still has other open blockers before it declares good news, so it never says "you're clear" while you're still stuck. There are three variants:

Bulk-change summary

When one person triggers a burst of slips at once — a sprint reshuffle that moves a dozen issues — Tripwire folds them into a single summary instead of a flood of comments. The summary is posted to the project's Dependency Digest issue (see Anti-spam).

Who gets notified

Each alert @-mentions the people best placed to react on the dependent side, so Jira's own notifications reach them. By default:

Recipients are configurable per project — you can turn the assignee or lead mention off, or add named people with the user picker. Tripwire resolves everyone by display name; if a lookup ever fails it degrades gracefully rather than exposing raw account IDs.

Built not to spam

The fastest way to get an alerting app uninstalled is to make it noisy. Tripwire has four layers of restraint:

• Once per day, per dependency, per kind. A 24-hour cooldown means the same edge won't alert twice for the same class of change in a day, no matter how many times the field wobbles.
• Burst folding. When one actor triggers more than a handful of slips within a few minutes (a bulk board reshuffle), the individual comments are folded into one summary on the digest issue.
• Write-before-post de-duplication. Tripwire records that it's about to alert before it posts, so a retried or duplicated platform event can never produce a duplicate comment.
• One-click mute. Every alert footer links to mute that project. Muted projects post nothing — but the dashboard keeps tracking state, so you still see the truth when you look.

The weekly digest

Once a week (on a weekday you choose), Tripwire posts a per-project digest — the Monday catch-up that replaces a cross-team status meeting. Each digest gathers what happened across that project's dependencies:

• New slips and punts since the last digest;
• Dependencies currently at risk (slipped, punted, or stale and still open);
• Wins — dependencies that got unblocked; and
• Any bulk-change summaries folded during the week.

The digest is posted as a comment on that project's lazily-created "Dependency Digest" issue (labelled tripwire-digest), rendered as rich Jira content, and is also available on the dashboard's Digest tab. If someone deletes the digest issue, Tripwire detects it and recreates it — the digest never silently dies. You can disable the digest or change its recipients and weekday in Settings.

The dashboard

Open Apps → Tripwire for a global page with four tabs — the 10-minute triage view for everything cross-team.

Settings

From the Settings tab you control all of Tripwire's behaviour:

Why an alert did — or didn't — fire

The most common support question is "I changed something and got no alert" (or the reverse). Tripwire is deliberately conservative; this table explains the logic.

Privacy & permissions

Tripwire is built on Atlassian Forge and runs entirely inside Atlassian Cloud. It makes no requests to any external server and stores only a small dependency layer over your issues (which issue blocks which, the state and slip count, the timestamps and date/sprint snapshots it needs to spot the next change, the anti-spam ledger, and your settings). It does not store your issue descriptions, comments, or attachments.

See the full Privacy Policy, Terms of Service, and Support SLA.

FAQ

Support

Questions, bugs, or feedback? Email support@outpostlabs.dev. We provide best-effort, asynchronous support — see the Support SLA for response targets.