# The event log

Inspect what arrived, follow it through every delivery attempt, search past events and know how long they are kept.

Source: https://docs.webhooker.eu/receive/events/

Every accepted request — and every rejected one — is stored and visible. The
event log is where you answer "did it arrive?", "what was in it?" and "what did
my app say?" without reading your own logs.

## Live tail

The source's **Overview** tab streams events as they arrive: a webhook that
lands while the page is open appears without a refresh. Each row shows the
method, the size, the verification result and the time.

![The event log of a source](https://docs.webhooker.eu/screenshots/source-overview-light.webp "The event log: method, time, delivery count, payload size and verification result per event.")

Live tail is a view, not a buffer. Closing the page loses nothing — the events
are already stored.

The number of concurrent live streams per workspace is capped by your plan, so
close tabs you are not watching. Programmatic access to the same stream is in
the [API reference](/reference/api/#live-streams).

## Event detail

Click an event to see:

![An event detail page with deliveries and body](https://docs.webhooker.eu/screenshots/event-detail-light.webp "An event detail page. Every delivery expands into its attempts, with status, latency and the response body.")

- **Request** — method, received time, content type and payload size.
- **Headers** — every inbound header, exactly as sent.
- **Body** — the raw payload, pretty-printed when it is JSON. Binary payloads
  are also available base64-encoded.
- **Verification** — `verified`, `failed` or `skipped`.
- **Deliveries** — one row per gateway, each expandable into its attempts:
  attempt number, target URL, response status, response body, error message and
  latency.

That last section is the one to screenshot when a provider or a teammate claims
a webhook never arrived.

## Searching

The events list can be narrowed by source, by verification result, by time
window, and by event id. The [API](/reference/api/#events) exposes the same
filters as query parameters, which is the easier route when you need to pull a
day's worth of failures into a script.

## Resending

Any stored event can be resent to its gateways from the event detail view. A
resend creates fresh deliveries and runs the normal retry schedule; disabled
gateways are included, because a resend is an explicit operator action. Bulk
replay for a whole backlog lives in the source's **Dead letters** tab —
see [retries and replay](/deliver/retries-and-replay/).

## Retention

Events are kept for the retention window of your plan — 14, 30 or 90 days — and
then permanently removed together with their deliveries and attempts. The window
is stamped on each event when it arrives, so upgrading a plan extends only the
events received afterwards.

Deleting a source moves it to the trash; its events are removed with it after
the 7-day grace period.

If you need webhook history beyond your retention window, forward the events to
a gateway that archives them on your side.