shadcn.io is not affiliated with official shadcn/ui
Webhook Delivery Log Table Block for React Aria
A webhook delivery log whose rows show each attempt as a chip with its back-off in words, filter chips for all, delivered and failed with counts, and a Retry now button that adds the next attempt.
Installation
Overview
Show what it took to get an event delivered, with this webhook delivery log for React with React Aria. A compact header names the log and holds three filter chips (All, Delivered, Failed), each with its count, built on a Toggle Group. Inside a hairline frame with a plus mark on each corner, a native table in a fixed-height region lists eight deliveries by event, endpoint, attempts and status. Each delivery draws its attempt chain as chips ("1 failed", "2 failed", "3 delivered") and, under them, the back-off between the attempts in words ("Retried after 1 min, 5 min"). A failed delivery with attempts remaining has a "Retry now" Button, which adds the next attempt from a typed script (the first retry fails, the second delivers) and says what happened in the polite line; one that has used all three attempts says "No attempts remain" instead. Nothing is sent. Once every failure has been retried, the Failed chip opens an empty state with a way back. On a phone the endpoint and the attempts wrap under the event name. It's built from Toggle Group, Badge, Button, Empty and Guides. For delivery dashboards, integration consoles and any log where a row can be retried.
FAQ
How is an attempt chain stored?
Each delivery in DELIVERIES has a script, the outcomes its attempts will have in order, and made, how many have happened. The chips are script.slice(0, made), the status is the last of them, and the wait before attempt two and three comes from BACKOFF ("1 min", "5 min"). Retry now only raises made by one, so the chain, the status, the counts on the chips and the polite line all follow from one number.
Does Retry now send anything?
No. It plays the next outcome of the typed script and the line under the heading says so ("Attempt 2 of invoice.paid delivered. Nothing was sent in this demo."). To wire it, call your retry endpoint in the press handler, append the attempt the server returns and keep the rest. Keep a cap on attempts (here three) in the data, so the button disappears when the server will refuse.
Where does focus go after a retry?
If the delivery can be retried again, the button stays and keeps focus. If the delivery has landed or is out of attempts, the button is removed, so focus moves to the table's region instead of falling to the page, and the status line reads the result. Reading order is unchanged.
How do the filter chips behave?
They are one choice of three, so pressing a chip replaces the last one. The counts are derived from the deliveries as they are now: retrying a failed delivery until it lands moves it from Failed to Delivered and both counts change. The table keeps its height whichever chip is pressed, and the Failed chip shows an empty state when nothing is left over.
Is it accessible?
Yes. It's a native table with a caption, column heads and a row header for each event. The chips are toggle buttons that say whether they are pressed, each Retry now button is named for its event ("Retry order.shipped now"), the attempt chips are a list with text rather than colour, and a polite status line is present from the start.