Your webhooks stop being a black box.
Every incoming call recorded with its headers, payload, rendered message and outcome. When an integration swears it sent the request, you can check.
Everything a failed webhook will not tell you
When an alert does not arrive, the question is always the same: did the sender actually call, and if it did, what went wrong on our side?
A log of every request
Every call recorded, newest first, expandable inline. Method, source IP, size and content type at a glance.
Headers and payload in full
The full headers and raw body exactly as they arrived, so you can compare what a service claims it sends with what it sent.
What your template produced
See the message your template rendered from the payload, next to the payload itself. Template bugs stop being guesswork.
Named failure reasons
Failures come with a specific reason: invalid JSON, an empty message from a missing %path%, or an inactive webhook.
Redacted and encrypted
Authorization, cookie and API-key headers are redacted before storage, and payloads are encrypted at rest with your key.
Filter, page, or fetch
Filter by outcome and page through the history in the dashboard, or pull it from the API and analyse it yourself.
Find out what actually arrived
Point a service at it
Create a webhook and point your service at its URL, as you would normally.
Open the history
Open the webhook in your dashboard and click through to its history.
Expand the call
Expand any call to see headers, body, the rendered message and what went wrong.
How webhook history works
Every request that reaches one of your webhook URLs is recorded before it is processed, and the outcome is attached once processing finishes. That means you see failed calls as clearly as successful ones — including calls to a webhook you disabled and forgot about.
Open a webhook in the dashboard and its history is there, newest first, each row expanding to show the query string, the full headers, and the body with JSON formatting. The same data is available from the REST API with filters for success and error.
Debugging a template
The most common failure is not a network problem, it is a %path% placeholder pointing at a field the sender does not actually send. The history shows the raw payload and the message your template produced side by side, which usually makes the mismatch obvious in seconds.
Privacy
Payloads often contain secrets, so they are encrypted at rest with your personal key, and Authorization, cookie and API-key headers are replaced with [redacted] before storage. Retention runs from 7 days on Free up to a full year on Large.
Questions, answered
Timestamp, HTTP method, source IP, content type, query string, full headers, the raw body, payload size, the message your template produced, whether an alert was created, a failure reason when it was not, and how long processing took.
7 days on Free, 30 on Starter, 90 on Medium and 365 on Large. Older calls are removed automatically, as are the oldest entries once a single webhook passes 1,000 recorded calls.
Yes. Payloads are encrypted at rest with your personal key, the same as message content, and Authorization, cookie and API-key headers are replaced with [redacted] before anything is stored.
The history tells you which. If nothing is recorded at all, the sender never reached us. If a call is recorded with an error, you get the reason: invalid JSON, an empty message from a %path% that does not exist in the payload, or a webhook that was disabled.
Open the webhook in your dashboard and its history is right there, newest first, with each call expandable. There is also a REST endpoint if you would rather pull it programmatically, with filters for success and error.
Yes, with 7 days of retention. If you need longer, that is what the paid plans extend.
Stop guessing why the alert never came
Point a service at a PocketAlert webhook and every call it makes is on the record, whether the alert worked or not.