The recent events list on a webhook's page shows the 50 newest events, limited in the query. Each row adds:
time received, relative, with the UTC timestamp on hover;
body size, read in SQL without loading the body;
processing time;
with exactly one HTTP target, its HTTP status: 2xx green, 3xx grey, 4xx yellow, 5xx red; "no response" (red) when the attempt got none, "pending" before any attempt, "not sent" when there is no delivery to it;
a "resubmitted copy" marker, as in the event log, since a copy otherwise looks like a real arrival.
Processing time is how long the event's slowest delivery took, from being queued to its last recorded attempt, retry waits included. Deliveries are queued on receipt, so this is receipt to final outcome; a replay is timed from the replay. It reads "in progress" while any delivery is pending or retrying, and is blank without deliveries. Existing timestamps suffice; nothing new is recorded.
Disclosures:
Judgement call: only HTTP targets count toward "exactly one"; other target types do not hide the column.
Judgement call: the status is from the newest delivery to the target, so a replay's answer replaces the original's.
Amber is the page's existing text-yellow-600; no class was missing, so tailwind.css is untouched.
The reused event log attempt loader also reads each attempt's response body (capped at 4 KB), unused here.
github.com/dustin/go-humanize, already indirect, is now direct.
Relative times are server-rendered and do not update while the page stays open.
Model: opus-5-5
Implements https://git.eeqj.de/sneak/webhooker/issues/347.
The recent events list on a webhook's page shows the 50 newest events, limited in the query. Each row adds:
- time received, relative, with the UTC timestamp on hover;
- body size, read in SQL without loading the body;
- processing time;
- with exactly one HTTP target, its HTTP status: 2xx green, 3xx grey, 4xx yellow, 5xx red; "no response" (red) when the attempt got none, "pending" before any attempt, "not sent" when there is no delivery to it;
- a "resubmitted copy" marker, as in the event log, since a copy otherwise looks like a real arrival.
**Processing time** is how long the event's slowest delivery took, from being queued to its last recorded attempt, retry waits included. Deliveries are queued on receipt, so this is receipt to final outcome; a replay is timed from the replay. It reads "in progress" while any delivery is pending or retrying, and is blank without deliveries. Existing timestamps suffice; nothing new is recorded.
Disclosures:
- Judgement call: only HTTP targets count toward "exactly one"; other target types do not hide the column.
- Judgement call: the status is from the newest delivery to the target, so a replay's answer replaces the original's.
- Amber is the page's existing `text-yellow-600`; no class was missing, so `tailwind.css` is untouched.
- The reused event log attempt loader also reads each attempt's response body (capped at 4 KB), unused here.
- `github.com/dustin/go-humanize`, already indirect, is now direct.
- Relative times are server-rendered and do not update while the page stays open.
Model: opus-5-5
The recent events list on a webhook's page now shows the 50 newest
events, each with its time relative to now (the full UTC timestamp on
hover), its body size, its processing time and, when the webhook has
exactly one HTTP target, that target's last HTTP status, colour-coded.
Resubmitted copies are marked, as in the event log.
Processing time is how long the event's slowest delivery took, from
being queued to its last recorded attempt. It is read from the existing
delivery and attempt timestamps, so nothing new is recorded. The body's
size is read in SQL, never the body.
Deliveries and attempts load in one batched query each, reusing the
event log's attempt loader.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implements #347.
The recent events list on a webhook's page shows the 50 newest events, limited in the query. Each row adds:
Processing time is how long the event's slowest delivery took, from being queued to its last recorded attempt, retry waits included. Deliveries are queued on receipt, so this is receipt to final outcome; a replay is timed from the replay. It reads "in progress" while any delivery is pending or retrying, and is blank without deliveries. Existing timestamps suffice; nothing new is recorded.
Disclosures:
text-yellow-600; no class was missing, sotailwind.cssis untouched.github.com/dustin/go-humanize, already indirect, is now direct.Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.