Integration Logs Table
Integration event log with timestamp, direction, event name, HTTP status badge, duration, and an expanded error detail row for failed events.
Integration event log with timestamp, direction, event name, HTTP status badge, duration, and an expanded error detail row for failed events.
Search blocks by description or jump to a page.
The source for every Application block is included with Basic and Pro. Pick a plan to copy the code.
Already purchased? Log in
Integration Logs Table is the event-by-event debugging view for a GitHub connection: six rows spanning Jun 13 12:41 to 14:02, each with timestamp, direction arrow (Inbound or Outbound), event name in monospace (push, statuses.create, pull_request.opened), HTTP status as a badge (200 secondary, 503 outline), and duration right-aligned in tabular-nums. The 503 row expands into a muted detail row naming the exact failure: GitHub returned 503 after the request timed out, deploy status not posted to pull request #841, and the honest note that Acme will not retry automatically. A footer states logs are retained 30 days and cannot be edited.
Rows are one const array; Fragment wraps each log so the detail row shares the key. The cannot-edit footer sets expectations before anyone asks.
Reach for this block on the detail page for a single integration, wired to your event log endpoint. Pair it with the sync status panel so users move from the summary view to the raw log without a separate page load.
A natural flow around it on an Application Pro page:
Before
After
One strong use is the GitHub webhook and API event log. Other integration log tables:
Tip: the expanded error row earns its space only when it gives the exact failure reason; a generic message is worse than no expansion at all.