Admin webhook ops
Webhook backlog and replay safety
Inspect provider events, spot failures or duplicate noise fast, and move into a single event detail without digging through raw payload data before you understand the operational problem.
Priority queue
Find the event worth opening next
List views should make severity, replay posture, and investigation priority obvious before anyone reads provider payload fields.
Backlog
0 recent webhook events
The queue should quickly separate problematic events from ordinary history so operators know what deserves attention first.
0 processed0 idempotency keys
Replay posture
Idempotency evidence stays attached to the queue
A webhook desk is only trustworthy if operators can tell whether replay will be safe before they click into the event.
Response hashes visibleReplay-aware
Audit
Replay actions remain durable and reviewable
Every replay should leave a clear administrative trace so there is no mystery about who re-triggered what and why.
Audit near the queue
Backlog
Recent provider events
Open the right event fast. The list should stay investigation-first rather than payload-first.
No webhook events have been recorded yet.
Replay safety
Idempotency posture remains readable
Response hashes, scopes, and recorded state belong on this page because they decide whether a replay is safe before you open the detail route.
No idempotency keys have been recorded yet.
Replay audit
No replay audit yetWebhook replays requested from admin will appear here.