Webhook logs

Every delivery Webhooks Pro makes is persisted — successful ones, HTTP errors, network failures, and replays. The Webhook Logs page is where admins troubleshoot, replay failures, and audit what was sent.

If anything ever goes wrong with a webhook, this is where you go first.

When to use it

A receiver isn't getting deliveries → check whether they're being sent and how the receiver responded.
A delivery failed → expand the row, read the response, replay if appropriate.
An auditor asks "what did we send to that endpoint?" → search by webhook + date.
You changed a payload template → watch the next few deliveries to confirm the new shape renders correctly.

How it works

Every delivery attempt produces exactly one row, regardless of outcome. Replays produce additional rows linked back to the original via sourceLogId. Rows older than the configured retention window are deleted automatically by the daily prune.

The page at a glance

Stats bar (top)

Four counters, refreshed on every page load:

Counter	Means

Counter	Means
Total	Delivery rows currently retained.
Success	2xx + 3xx responses.
Failed	4xx + 5xx + Network Error.
Avg Execution Time	Mean round-trip across visible logs.

Skipped rows (license-blocked) are deliberately excluded — see the Limits section below.

Filters

Five controls + a date picker + a toggle. Full reference: Filter and search logs.

The table

One row per delivery attempt. Click any row (or its chevron) to expand a lazy-loaded detail panel with the full request and response. Full walkthrough: Inspect a delivery.

Replay

A Run again button on each eligible row, plus a bulk-action bar when you select multiple. Full reference: Replay a delivery (Run again).

Sub-pages

Status colour legend

Lozenge	Meaning

Lozenge	Meaning
Green 2xx	Success — receiver accepted the body.
Blue 3xx	Redirect.
Amber 4xx	Client error — usually wrong body, missing auth, or a config issue on the webhook side.
Red 5xx	Server error — receiver-side.
Red Network Error (`0`)	No HTTP response — timeout, DNS failure, refused connection.
Neutral Skipped — license …	Webhooks Pro intentionally did not attempt the request because the licence state doesn't allow delivery.

The split lines up with the Run again button filter on Tenant settings → Webhooks — that setting controls which categories show the replay button.

What gets persisted

Stored	Not stored

Stored	Not stored
URL, HTTP method, query params, user-defined headers	System headers (`X-Webhook-Event`, `X-Webhook-Timestamp`, `X-Webhook-Agent`, `Content-Type`) — identical on every delivery
Request body (rendered)	The raw event before template render
HTTP status code (or `0`)
Response body and headers
Network error message (when applicable)
Initiator accountId, event type, execution time
`sourceLogId` for replays

Bodies above a small threshold are gzipped before storage; the log viewer transparently decompresses for display.

Limits and gotchas

Skipped rows are excluded from Stats and from the per-webhook auto-disable failure counter. An installation-wide licence problem doesn't penalise individual webhooks. See Subscription states and SEN.
Retention is tenant-wide, not per-webhook. Default 14 days. See Log retention.
JQL-rejected events leave no log row. If you expect a delivery and there's no row at all, your JQL likely didn't match. See JQL filter didn't match.
Coalesced events leave one row, not many. Debounce collapses bursts before they reach the log. See Debounce and coalescing.
Replays use current Jira state, not the snapshot from the original delivery. The replayed payload reflects the issue as it is now.
System headers aren't in the row detail. Only your own headers are persisted. The system headers Webhooks Pro adds (X-Webhook-Event, X-Webhook-Timestamp, X-Webhook-Agent, Content-Type default) are deterministic and not stored.

Common diagnostic flows

Symptom	Where to start

Symptom	Where to start
No row appears for an event you expected	JQL filter didn't match → check JQL → check webhook is enabled → check Events tab
Status `0` in red	Status code 0 and network errors
HMAC signature rejected by receiver	HMAC signature mismatch on the receiver
Receiver returns `200` but doesn't show the data	Open the row → Body. Compare with what the receiver expects. Adjust template.
Webhook auto-disabled	Re-enable an auto-disabled webhook

For the broader playbook: Diagnose a failing delivery.

Webhooks — what produces these deliveries.
Tenant settings → Run-again ranges, Auto-disable, Request timeout, Log retention.
Delivery queue — what's in flight (pre-delivery), as opposed to what's been delivered (logs).
Diagnose a failing delivery — full diagnostic walkthrough.
Subscription states and SEN — explains the Skipped lozenge.