Webhook Delivery Logs

Inspect every webhook delivery, see why one failed, and retry with one click.

What this gives you

When you configure a webhook alert channel, Signalog POSTs every alert to your endpoint. Sometimes those deliveries fail. Your endpoint is down, returns 500, or times out. Without delivery logs, you find out only when the customer complains they didn’t get the alert.

Webhook delivery logs show every delivery attempt with full request/response details, plus a one-click retry button. Available on Pro and Business.

Where to find delivery logs

  1. Open Settings → Alert channels (admin role)
  2. Click any webhook channel
  3. Click the Deliveries tab

You’ll see the last 100 deliveries, newest first. Each row shows:

  • Timestamp: when we attempted delivery
  • Status: success (2xx), failure (4xx/5xx/timeout/network error)
  • Response code: hTTP status from your endpoint (or — if no response)
  • Latency: how long the request took (or “timeout” if it exceeded 10s)
  • Incident: link to the incident the alert was about

Click any row to see full details:

  • Request: method, URL, headers (including HMAC signature), body
  • Response: status code, headers, body (truncated to 64KB)
  • Error: for non-HTTP failures (DNS, connection refused, TLS errors)

When to use it

”The webhook didn’t fire”

Check the deliveries log for the affected incident’s timeframe.

  • No row → the alert never tried to deliver. Check the channel is enabled and routing rules apply.
  • Failed row → delivery was attempted but failed. The response body usually tells you why.

”I deployed a fix to my endpoint, can I re-send the failed alerts?”

Yes. That’s exactly what the Retry button is for. Click it on any failed delivery and Signalog re-attempts with the original payload.

Retries don’t fan out to other channels. Only the one you clicked. If you want to retry to multiple channels, retry each one individually.

”Is my endpoint receiving the right HMAC signature?”

Open a successful delivery’s request details. The X-Signalog-Signature header shows what we sent. Verify your endpoint computes the same HMAC over the body using your channel’s signing secret.

The signature format is:

X-Signalog-Signature: t=1735689600,v1=hex_hmac_sha256

Where t is the request timestamp (Unix seconds, used to prevent replay attacks) and v1 is HMAC-SHA256(secret, "{t}.{body}") in hex.

”I keep seeing 401s. What’s the auth?”

Check what your endpoint expects. Some common patterns:

  • No auth + HMAC verification (recommended). Verify the signature header instead of API key auth
  • API key in header: set a custom header in the channel config (X-API-Key: ...)
  • API key in URL: embed in the channel’s URL field (https://example.com/webhook?token=...)

Retry behavior

By default, Signalog doesn’t auto-retry failed deliveries. The reasoning: webhook delivery failures usually mean your endpoint is down, and auto-retrying every 30 seconds compounds the problem during an outage.

You have two options:

  1. Manual retry: click the Retry button after fixing your endpoint
  2. Channel-level auto-retry: opt in per-channel from the channel settings; retries 3 times with exponential backoff (1m, 5m, 30m)

For mission-critical alerts where missing one is worse than duplicates, enable auto-retry. For idempotent endpoints that already handle duplicate alerts, manual retry is usually fine.

The deliveries view supports filtering:

  • Status: success / failure / pending
  • Time range: last 1h / 24h / 7d
  • Incident: filter to deliveries for one specific incident

For longer-term analysis, use the API:

GET /api/v1/alerts/{channelId}/deliveries?since=2026-01-01&status=failure

The endpoint returns the last 1000 deliveries (paginated), with full details for each.

Retention

Delivery logs are retained for 30 days regardless of plan. After that, they’re aged out. The alert itself is preserved (incidents have full retention based on plan), but the per-delivery details are gone.

If you need longer retention for compliance, export periodically via the API.

Performance impact

Each delivery write hits Postgres asynchronously. It doesn’t slow down the alert pipeline. If the database is briefly unavailable, deliveries continue (and the log writes catch up after).

For very high-volume webhooks (thousands per minute), the log table can grow quickly. The 30-day retention keeps it bounded; contact us if you need different retention behavior.

What’s NOT in delivery logs

  • Slack / Discord / PagerDuty / Email: those use provider APIs, not raw webhooks. Their delivery state is captured in the audit log, but not in the deliveries view (which is webhook-specific).
  • Push notifications: web push uses the browser’s push service, which is delivered eventually-ish. Failures aren’t visible to Signalog.
  • SMS / Voice (Twilio): Twilio has its own delivery dashboard. Use that.

Plan availability

Webhook delivery logs are Pro and Business. Free-tier teams can configure webhooks but don’t get the deliveries view.

Next steps