Context
Part of Channels v1.0 (#4503). The channel logs table shows what happened — this page shows why.
What we're building
A detail page for individual channel requests so users can inspect the full HTTP request/response pair for debugging and audit.
Mockup

Detail page sections
- Summary card — method, path, status code, state pill, timestamps, latency, client IP, auth type, request ID
- Request — headers table, body preview with size and hash
- Response — three states: normal (status + headers + body), transport error (humanized message like "DNS lookup failed"), credential error (humanized message, no timing)
- Timing — visual breakdown of TTFB vs response download
- Context — snapshot of channel config at request time, with indicator when config has changed since
Supporting changes
- New schema fields on
channel_events — query string, body sizes, response duration. Data that Philter already computes but Lightning currently discards.
- Headers migration — convert from text (JSON string) to native jsonb
- Client auth tracking on
channel_requests — which auth method was used (survives deletion)
- Error humanization — classified error codes → human-readable messages
- Navigation — request ID links from the logs table, breadcrumbs, route
Explicitly deferred
- Request replay, body download
Implementation
Detailed spec and component mapping tracked externally.
Context
Part of Channels v1.0 (#4503). The channel logs table shows what happened — this page shows why.
What we're building
A detail page for individual channel requests so users can inspect the full HTTP request/response pair for debugging and audit.
Mockup

Detail page sections
Supporting changes
channel_events— query string, body sizes, response duration. Data that Philter already computes but Lightning currently discards.channel_requests— which auth method was used (survives deletion)Explicitly deferred
Implementation
Detailed spec and component mapping tracked externally.