V208: the bucket log (dev_docs/plans/2026-10-03-bucket-page.md, section 6).
phoenix_kit_bucket_log records what went wrong with a site storage bucket
(a write, read or delete that failed) and what its connection probes said,
with the time each took, so the bucket's own page can show a failing bucket
and its latency over time. Until now such failures reached only Logger.
kind—probe,write,readordelete;ok— whether it succeeded (a probe can; the rest are only recorded when they fail, so the table stays small on a healthy bucket);latency_ms— how long a probe took;message— what the provider said, truncated by the writer, never a key;count,inserted_at,last_at— the same failure seen again within a minute is one row whosecountgrows andlast_atmoves, so a bucket that is down does not write a row per request.
There is no foreign key on bucket_uuid, the choice V206 and V207 made: a
row must not block deleting a bucket (Storage.delete_bucket/2 removes the
bucket's rows itself), and a log write must never fail because a bucket was
deleted meanwhile. A user's own bucket (V206) is never logged.
The log is operational, not an audit: it is pruned daily to
bucket_log_retention_days (default 30). Nothing is copied, moved or
rewritten; the table starts empty.
Locks
CREATE TABLE and CREATE INDEX on a table nothing references. Re-runnable.
Summary
Functions
Rolls V208 back: the log is only history, so the table simply goes.
The kinds of entry the log holds.