in the target list, each target should show how many successful and unsuccessful deliveries it has had, both in total, as well as in the last 24h.
PRIORITY: an owner's direct request of 1 October, in the tier of #367 to #370: after the production path, ahead of the older backlog.
Related: #368 (the statistics pane, whose plan keeps lifetime totals that survive retention pruning, and counts by delivery final status and time) and #370 (the targets section's add flow). Reuse 368's mechanism, counted per target rather than per webhook. Do not build a second one.
Definition of done:
Every target in the per-webhook page's target list shows four figures: successful deliveries in total and in the last 24 hours, and failed deliveries in total and in the last 24 hours.
"Total" is lifetime and stays correct after retention removes old deliveries. "Successful" and "failed" mean a delivery's final status, delivered or failed. Deliveries still pending or retrying count in neither.
No full scan per page view: totals come from stored counters, the 24-hour figures from an indexed range.
Pre-1.0: the schema changes in place, with no migration and no back-fill.
Tests cover the four figures for more than one target, including across a retention prune. Lands on next with an independent review, sequenced with 368 and 370, which touch the same page.
model: opus-5-5
Owner's words (chat, 2026-10-01 ~19:04 UTC):
> in the target list, each target should show how many successful and unsuccessful deliveries it has had, both in total, as well as in the last 24h.
PRIORITY: an owner's direct request of 1 October, in the tier of https://git.eeqj.de/sneak/webhooker/issues/367 to https://git.eeqj.de/sneak/webhooker/issues/370: after the production path, ahead of the older backlog.
Related: https://git.eeqj.de/sneak/webhooker/issues/368 (the statistics pane, whose plan keeps lifetime totals that survive retention pruning, and counts by delivery final status and time) and https://git.eeqj.de/sneak/webhooker/issues/370 (the targets section's add flow). Reuse 368's mechanism, counted per target rather than per webhook. Do not build a second one.
Definition of done:
- Every target in the per-webhook page's target list shows four figures: successful deliveries in total and in the last 24 hours, and failed deliveries in total and in the last 24 hours.
- "Total" is lifetime and stays correct after retention removes old deliveries. "Successful" and "failed" mean a delivery's final status, delivered or failed. Deliveries still pending or retrying count in neither.
- No full scan per page view: totals come from stored counters, the 24-hour figures from an indexed range.
- Pre-1.0: the schema changes in place, with no migration and no back-fill.
- Tests cover the four figures for more than one target, including across a retention prune. Lands on `next` with an independent review, sequenced with 368 and 370, which touch the same page.
model: opus-5-5
clawbot
self-assigned this 2026-10-01 21:04:39 +02:00
Builds on #368's running totals and its indexed final-status time, which 368 keeps per target as well as per webhook (108111). If 368 lands without per-target totals, this issue extends the same table to one row per target; it adds no second mechanism.
Each row of the target list shows delivered and failed, in total and in the last 24 hours. Totals come from the per-target running totals, so they survive retention pruning. The 24-hour figures are an indexed count of that target's deliveries that reached delivered or failed in the last 24 hours. Pending and retrying deliveries count in neither.
The figures for all of a webhook's targets come from one query each, grouped by target, not one query per target.
Sequencing: after 368, and after #370, which reworks the same section.
Model: opus-5-5
Plan.
- Builds on https://git.eeqj.de/sneak/webhooker/issues/368's running totals and its indexed final-status time, which 368 keeps per target as well as per webhook (108111). If 368 lands without per-target totals, this issue extends the same table to one row per target; it adds no second mechanism.
- Each row of the target list shows delivered and failed, in total and in the last 24 hours. Totals come from the per-target running totals, so they survive retention pruning. The 24-hour figures are an indexed count of that target's deliveries that reached delivered or failed in the last 24 hours. Pending and retrying deliveries count in neither.
- The figures for all of a webhook's targets come from one query each, grouped by target, not one query per target.
- Sequencing: after 368, and after https://git.eeqj.de/sneak/webhooker/issues/370, which reworks the same section.
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 ~19:04 UTC):
PRIORITY: an owner's direct request of 1 October, in the tier of #367 to #370: after the production path, ahead of the older backlog.
Related: #368 (the statistics pane, whose plan keeps lifetime totals that survive retention pruning, and counts by delivery final status and time) and #370 (the targets section's add flow). Reuse 368's mechanism, counted per target rather than per webhook. Do not build a second one.
Definition of done:
nextwith an independent review, sequenced with 368 and 370, which touch the same page.model: opus-5-5
Plan.
Model: opus-5-5