also it should have a pane at the top that shows all of the statistics (lifetime and per-retention-period) for that webhook - how many sources, how many destinations, how many events, how many deliveries, how many failures, failures in the last 10 minutes, failures in the last 24h, failure percentage last 10 mins, failure percentage last 24h, etc.
"It" is the per-webhook page (see the route change filed alongside this issue).
Definition of done:
At the top of the per-webhook page, a pane shows that webhook's statistics:
how many sources and how many destinations;
events, deliveries and failures, each both lifetime and within the retention period;
failures in the last 10 minutes and in the last 24 hours;
the failure percentage over the last 10 minutes and over the last 24 hours;
other figures of the same kind that the data supports ("etc.").
Lifetime figures stay correct after retention removes old events. The issue comments state, before implementation, how lifetime counts survive pruning, and how each percentage is defined (failed deliveries over all deliveries in the window).
The page stays fast with large event counts: no full scan per page view, and the comment says how.
Tests cover every figure, including across a retention prune. Lands on next with an independent review.
model: opus-5-5
Owner's words (chat, 2026-10-01 ~18:5x UTC):
> also it should have a pane at the top that shows all of the statistics (lifetime and per-retention-period) for that webhook - how many sources, how many destinations, how many events, how many deliveries, how many failures, failures in the last 10 minutes, failures in the last 24h, failure percentage last 10 mins, failure percentage last 24h, etc.
"It" is the per-webhook page (see the route change filed alongside this issue).
Definition of done:
- At the top of the per-webhook page, a pane shows that webhook's statistics:
- how many sources and how many destinations;
- events, deliveries and failures, each both lifetime and within the retention period;
- failures in the last 10 minutes and in the last 24 hours;
- the failure percentage over the last 10 minutes and over the last 24 hours;
- other figures of the same kind that the data supports ("etc.").
- Lifetime figures stay correct after retention removes old events. The issue comments state, before implementation, how lifetime counts survive pruning, and how each percentage is defined (failed deliveries over all deliveries in the window).
- The page stays fast with large event counts: no full scan per page view, and the comment says how.
- Tests cover every figure, including across a retention prune. Lands on `next` with an independent review.
model: opus-5-5
clawbot
self-assigned this 2026-10-01 20:54:39 +02:00
Terms. The "sources" and "destinations" are the webhook's entrypoints and targets. A failure is a delivery whose final status is failed; replays count as deliveries, resubmitted copies as events.
Figures: entrypoints and targets (active and total); events, deliveries and failures, each lifetime and within retention; failures and failure percentage over the last 10 minutes and the last 24 hours; and, of the same kind, events received in those two windows, deliveries in progress now (pending or retrying), and when the last event arrived.
How lifetime counts survive pruning. Each webhook's event database gets a one-row table of running totals: events, deliveries and failures, plus how many of each the retention sweep has removed. Storing an event, creating a delivery and recording a delivery's final failure each add one, in the same transaction as the row they count; the sweep adds what it deletes, in its own transaction. Lifetime is the running total; within retention is the running total minus what the sweep removed. Any other path that removes events or deliveries keeps the totals right too. On upgrade the totals start from the rows still stored, since what was pruned before is gone; the PR says so.
Percentages. Over a window, the failure percentage is the deliveries that reached failed within the window divided by the deliveries that reached a final status (delivered or failed) within it. Deliveries still pending or retrying are not counted. With none finished in the window, the pane shows a dash, not 0%. That needs the time a delivery reached its final status: a new column, set when the status becomes delivered or failed and indexed together with the status. Deliveries already final at upgrade take their last-updated time.
No full scan. The lifetime and within-retention figures read the one row of totals. The window figures are counts over an index range (events by the time received, which is already indexed; deliveries by final status and its time), so they cost what the window holds, not the whole stored history. Entrypoint and target counts come from the main database, which holds few rows.
Sequencing. This builds alongside #367: the pane is its own template, included at the top of the webhook page, so the two changes meet only at that include line and the handler that renders the page. Whichever lands second rebases.
Model: opus-5-5
Plan.
**Terms.** The "sources" and "destinations" are the webhook's entrypoints and targets. A failure is a delivery whose final status is failed; replays count as deliveries, resubmitted copies as events.
**Figures:** entrypoints and targets (active and total); events, deliveries and failures, each lifetime and within retention; failures and failure percentage over the last 10 minutes and the last 24 hours; and, of the same kind, events received in those two windows, deliveries in progress now (pending or retrying), and when the last event arrived.
**How lifetime counts survive pruning.** Each webhook's event database gets a one-row table of running totals: events, deliveries and failures, plus how many of each the retention sweep has removed. Storing an event, creating a delivery and recording a delivery's final failure each add one, in the same transaction as the row they count; the sweep adds what it deletes, in its own transaction. Lifetime is the running total; within retention is the running total minus what the sweep removed. Any other path that removes events or deliveries keeps the totals right too. On upgrade the totals start from the rows still stored, since what was pruned before is gone; the PR says so.
**Percentages.** Over a window, the failure percentage is the deliveries that reached failed within the window divided by the deliveries that reached a final status (delivered or failed) within it. Deliveries still pending or retrying are not counted. With none finished in the window, the pane shows a dash, not 0%. That needs the time a delivery reached its final status: a new column, set when the status becomes delivered or failed and indexed together with the status. Deliveries already final at upgrade take their last-updated time.
**No full scan.** The lifetime and within-retention figures read the one row of totals. The window figures are counts over an index range (events by the time received, which is already indexed; deliveries by final status and its time), so they cost what the window holds, not the whole stored history. Entrypoint and target counts come from the main database, which holds few rows.
**Sequencing.** This builds alongside https://git.eeqj.de/sneak/webhooker/issues/367: the pane is its own template, included at the top of the webhook page, so the two changes meet only at that include line and the handler that renders the page. Whichever lands second rebases.
Model: opus-5-5
Correction to the plan in 108022, from the owner's ruling on 367 (chat, 2026-10-01 ~19:01 UTC): webhooker is pre-1.0 prototype software with no users. Drop the upgrade handling. No "totals start from the rows still stored on upgrade", no back-filling the final-status time for existing deliveries, no new migration file. The schema change goes into the existing schema in place, and the PR says once, plainly, that an existing database must be recreated.
model: opus-5-5
Correction to the plan in 108022, from the owner's ruling on 367 (chat, 2026-10-01 ~19:01 UTC): webhooker is pre-1.0 prototype software with no users. Drop the upgrade handling. No "totals start from the rows still stored on upgrade", no back-filling the final-status time for existing deliveries, no new migration file. The schema change goes into the existing schema in place, and the PR says once, plainly, that an existing database must be recreated.
model: opus-5-5
Linked: #372 (owner, ~19:04 UTC) wants successful and failed deliveries per target, in total and in the last 24h, in the target list. Design this issue's running totals and final-status index so they also count per target. 372 then reuses them instead of adding a second mechanism.
model: opus-5-5
Linked: https://git.eeqj.de/sneak/webhooker/issues/372 (owner, ~19:04 UTC) wants successful and failed deliveries per target, in total and in the last 24h, in the target list. Design this issue's running totals and final-status index so they also count per target. 372 then reuses them instead of adding a second mechanism.
model: opus-5-5
the per-webhook page does not show the webhook's retention period.
This adds to the definition of done: the statistics pane at the top of the per-webhook page shows the webhook's retention period in plain units (for example "Retention: 30 days"), next to the within-retention figures it qualifies. A test checks it. If this issue lands later than the others, the retention period goes into the page header in a small change of its own first, so the page is not without it meanwhile.
model: opus-5-5
Owner's addition (chat, 2026-10-01 ~19:20 UTC):
> the per-webhook page does not show the webhook's retention period.
This adds to the definition of done: the statistics pane at the top of the per-webhook page shows the webhook's retention period in plain units (for example "Retention: 30 days"), next to the within-retention figures it qualifies. A test checks it. If this issue lands later than the others, the retention period goes into the page header in a small change of its own first, so the page is not without it meanwhile.
model: opus-5-5
Found again by the audit for #377, on current next: the webhook page shows its retention period only in the small grey line under Recent Events; there is no statistics pane.
Model: opus-5-5
Found again by the audit for https://git.eeqj.de/sneak/webhooker/issues/377, on current `next`: the webhook page shows its retention period only in the small grey line under Recent Events; there is no statistics pane.
Model: opus-5-5
Built in #403, following the plan above as corrected.
The webhook page now opens with a statistics pane: entrypoints and targets (and how many are active), deliveries in progress, when the last event arrived, the retention period; events, deliveries and failures, lifetime and within retention; and events, failures and failure percentage over the last 10 minutes and the last 24 hours.
Lifetime figures come from a row of running totals in each webhook's event database. The row is updated in the same transaction as the rows it counts, and the retention sweep adds what it removes. The window figures are counts over index ranges, using a new finished_at column on deliveries at the end of the status index. An existing database must be recreated.
Judgement call: the retention sweep's deletes now run in one transaction with the totals update, so a sweep holds the event database's write lock for all of its deletes at once.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/403, following the plan above as corrected.
The webhook page now opens with a statistics pane: entrypoints and targets (and how many are active), deliveries in progress, when the last event arrived, the retention period; events, deliveries and failures, lifetime and within retention; and events, failures and failure percentage over the last 10 minutes and the last 24 hours.
Lifetime figures come from a row of running totals in each webhook's event database. The row is updated in the same transaction as the rows it counts, and the retention sweep adds what it removes. The window figures are counts over index ranges, using a new `finished_at` column on deliveries at the end of the status index. An existing database must be recreated.
- Judgement call: the retention sweep's deletes now run in one transaction with the totals update, so a sweep holds the event database's write lock for all of its deletes at once.
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.
Owner's words (chat, 2026-10-01 ~18:5x UTC):
"It" is the per-webhook page (see the route change filed alongside this issue).
Definition of done:
nextwith an independent review.model: opus-5-5
Plan.
Terms. The "sources" and "destinations" are the webhook's entrypoints and targets. A failure is a delivery whose final status is failed; replays count as deliveries, resubmitted copies as events.
Figures: entrypoints and targets (active and total); events, deliveries and failures, each lifetime and within retention; failures and failure percentage over the last 10 minutes and the last 24 hours; and, of the same kind, events received in those two windows, deliveries in progress now (pending or retrying), and when the last event arrived.
How lifetime counts survive pruning. Each webhook's event database gets a one-row table of running totals: events, deliveries and failures, plus how many of each the retention sweep has removed. Storing an event, creating a delivery and recording a delivery's final failure each add one, in the same transaction as the row they count; the sweep adds what it deletes, in its own transaction. Lifetime is the running total; within retention is the running total minus what the sweep removed. Any other path that removes events or deliveries keeps the totals right too. On upgrade the totals start from the rows still stored, since what was pruned before is gone; the PR says so.
Percentages. Over a window, the failure percentage is the deliveries that reached failed within the window divided by the deliveries that reached a final status (delivered or failed) within it. Deliveries still pending or retrying are not counted. With none finished in the window, the pane shows a dash, not 0%. That needs the time a delivery reached its final status: a new column, set when the status becomes delivered or failed and indexed together with the status. Deliveries already final at upgrade take their last-updated time.
No full scan. The lifetime and within-retention figures read the one row of totals. The window figures are counts over an index range (events by the time received, which is already indexed; deliveries by final status and its time), so they cost what the window holds, not the whole stored history. Entrypoint and target counts come from the main database, which holds few rows.
Sequencing. This builds alongside #367: the pane is its own template, included at the top of the webhook page, so the two changes meet only at that include line and the handler that renders the page. Whichever lands second rebases.
Model: opus-5-5
Correction to the plan in 108022, from the owner's ruling on 367 (chat, 2026-10-01 ~19:01 UTC): webhooker is pre-1.0 prototype software with no users. Drop the upgrade handling. No "totals start from the rows still stored on upgrade", no back-filling the final-status time for existing deliveries, no new migration file. The schema change goes into the existing schema in place, and the PR says once, plainly, that an existing database must be recreated.
model: opus-5-5
Linked: #372 (owner, ~19:04 UTC) wants successful and failed deliveries per target, in total and in the last 24h, in the target list. Design this issue's running totals and final-status index so they also count per target. 372 then reuses them instead of adding a second mechanism.
model: opus-5-5
Owner's addition (chat, 2026-10-01 ~19:20 UTC):
This adds to the definition of done: the statistics pane at the top of the per-webhook page shows the webhook's retention period in plain units (for example "Retention: 30 days"), next to the within-retention figures it qualifies. A test checks it. If this issue lands later than the others, the retention period goes into the page header in a small change of its own first, so the page is not without it meanwhile.
model: opus-5-5
Found again by the audit for #377, on current
next: the webhook page shows its retention period only in the small grey line under Recent Events; there is no statistics pane.Model: opus-5-5
Built in #403, following the plan above as corrected.
The webhook page now opens with a statistics pane: entrypoints and targets (and how many are active), deliveries in progress, when the last event arrived, the retention period; events, deliveries and failures, lifetime and within retention; and events, failures and failure percentage over the last 10 minutes and the last 24 hours.
Lifetime figures come from a row of running totals in each webhook's event database. The row is updated in the same transaction as the rows it counts, and the retention sweep adds what it removes. The window figures are counts over index ranges, using a new
finished_atcolumn on deliveries at the end of the status index. An existing database must be recreated.Model: opus-5-5