Guides
Search Delivery Logs
Find events by what's actually in the payload — not just by date, endpoint, event type, or status — and combine that search with any of those existing filters at the same time.
How matching works
Free-text substring, not a structured query
Your search term is matched against the entire serialized payload as text — not a field-specific lookup. If the term appears anywhere in the payload's JSON, it matches.
Multiple terms are ANDed
Space-separated terms all have to appear (in any position) for an event to match. Matching is case-insensitive.
Minimum 3 characters
Shorter queries are rejected with a validation error rather than silently running a slow, low-signal search.
Scoped to one Application, within the retention window
Same scope as the rest of Delivery Logs — no cross-application search, and nothing outside the 30-day retention window is considered (there's no reason to search data that's about to be purged anyway).
Combines with your existing filters
Search isn't a separate mode — it's just another filter, ANDed together with date range, endpoint, event type, and status, regardless of which you set first.
Dashboard → Delivery Logs → Search (Enter or the Search button — never fires as you type)
Search also applies to CSV export —
if you have a search term active when you export, the CSV only contains matching rows, subject
to the same 10,000-row cap as any other export.
Built to be swappable later
Search runs behind an internal interface, not hardcoded to one database engine — today's implementation is PostgreSQL-native (a trigram index over the payload), chosen because it's sufficient at current scale, not because it's the only option forever.
This is an implementation detail, not something you configure — mentioned here only so you know
search behavior (matching semantics, scope, the 3-character minimum) is a stable contract even
if the underlying engine ever changes.