Delivery queue

The Delivery queue is a live view of webhook deliveries waiting to fire. Most of the time it's empty — the queue drains within seconds. When it isn't, this is where you diagnose stuck or slow deliveries.

Every Jira event is debounced (see Debounce and coalescing) and held in the queue as one row keyed by:

• element_id — numeric id of the entity the event is about. For updated:issue it's the issue id; for commented:issue it's the comment id; etc.

• event_type — Forge event key, e.g. avi:jira:updated:issue.

A row lives in the queue from the moment the event arrives until the debounce window expires and the delivery fires. If a new matching event arrives during the window, the existing row's debounce timestamp resets — that's how rapid edits collapse into a single delivery.

Rows in PROCESSING have a light amber background to stand out from PENDING.

• Family — narrow the visible rows to a specific event family. Choices: All families, Issue, Comment, Worklog, Attachment, Issue Link, Project, Version, Component, User, Filter, Issue Type, Field, Field Context, Workflow, Custom, Other.

The filter is client-side. Header actions (Flush, Delete all) operate on the full queue regardless of what's filtered.

Pushes every PENDING row into delivery immediately, skipping the rest of the debounce window. Good for:

• Smoke-testing a webhook you just saved — you don't want to wait 25 seconds.

• Clearing a backlog after a receiver outage where rows piled up while the receiver was down.

A confirmation message shows how many rows were flushed.

Manual reload. The page also auto-refreshes every 10 seconds, so you rarely need this — but it's handy after Flush now to see the result immediately.

Removes every queue row, regardless of status or filter. Confirmation: "Delete all N queue row(s)? This cannot be undone."

Use with care — dropped rows are not replayed and don't produce a delivery log entry. Intended for:

• Cleaning up a test environment.

• Recovering after a migration or schema change where queue state is no longer trustworthy.

Don't use Delete all as a routine "reset" — those events will never be sent.

Visible only on rows in PROCESSING. Resets the row to PENDING and clears its processing_version, so the next consumer wake picks it up fresh.

Use when a consumer crashed mid-delivery and a row is stuck in PROCESSING past its debounce window. The early warning is the Debounce Until column showing red with overdue.

A daily maintenance job also clears stuck rows automatically — Release is the manual way to unblock a specific row without waiting.

Always available. Removes the single row without firing the delivery. No confirmation dialog — one click is enough.

Use when a specific event was triggered by mistake (e.g. a scripted bulk edit) and you want to skip the webhook for that one entity without disabling the whole webhook.

Open

This is how Webhooks Pro guarantees that a late edit during processing isn't lost: the version bump signals that more state landed and another fire is owed.

• Successful deliveries — they leave the queue immediately and live in Webhook logs.

• Failed deliveries — same; the failure is in the log, not the queue.

• Skipped deliveries (licence) — never enter the queue.

• JQL-rejected events — never enter the queue.

• Schedules waiting for their next CRON match — that's a different mechanism (Forge's 5-minute scheduled trigger), not the queue.

• Debounce and coalescing — why rows stay in the queue.

• Webhook logs — what queue rows turn into after delivery.

• Tenant settings → Debounce window — controls how long rows stay.

• Status code 0 and network errors — why the queue might fill if the receiver is unreachable.