Logs and filters
The plugin's own send log: queue statuses, retries, and what to look at when an event has not arrived.
updated
Outline — facts still to be confirmed
This article is a structured outline. Its headings and scope are settled; the
specific values, screens and steps are marked TODO(owner: verify)
until they have been checked against the plugin itself. Blueprint §7 is explicit
that no article may state plugin behaviour that has not been verified.
The log doubles as the durable queue, so every row is both a record and a work item.
Statuses
| Status | Meaning |
|---|---|
queued |
Accepted, not yet sent. |
retrying |
A send failed and is scheduled to be retried. |
sent |
Delivered and acknowledged by the platform. |
failed |
Retries exhausted. |
browser |
The browser-side copy, recorded for comparison. |
unreachable |
The configuration cannot deliver this event — see Diagnostics. |
Retries
A failed send is retried after 1 minute, then 5, then 30, and is marked failed after that. The access token is read at send time rather than at queue time, so rotating a token never strands events that were already waiting.
Batches are capped at 1000 events per drain.
Outline still to fill
TODO(owner: verify) — available filters, retention period, whether failed rows can be re-queued manually, and what a redacted payload looks like on screen.
Was this page helpful?