@@ -8,6 +8,43 @@ taking.
 Releases before 0.6.0 have their notes on the
 [GitHub releases page](https://github.com/OpenLabs-so/openanalytics/releases).
 
+## [0.8.0] - 2026-09-19
+
+**Upgrade notes: nothing by hand — and going back is a restore.**
+`./upgrade.sh` as always. ClickHouse migration 0029 drops the ten hourly
+rollup tables 0.7.0 stopped writing, so **returning to 0.7.0 is not a matter
+of changing the image tag**: the older images would find those tables gone.
+Go back with `./rollback.sh` to the snapshot the upgrade took. Skipping 0.7.0
+(0.6.0 → 0.8.0) is supported: migrations 0025–0029 run in one pass and the
+migrate container fills the fifteen-minute rollups from your raw events
+afterwards, exactly as in 0.7.0. Details in `SELF-HOSTING.md`, "Upgrades and
+going back".
+
+### Fixed
+
+- **No more false "history fill failed".** The fill that builds the
+  fifteen-minute rollups from history now checks its result against the raw
+  events instead of the frozen hourly tables. In 0.7.0, an event the worker
+  delivered from its queue after the switch — with a timestamp inside the
+  filled history — reached the new tables and the raw events but not the
+  hourly ones, and the first start logged `history fill backfill-15m failed`
+  with `additive_mismatch` over data that was correct. The check now fails
+  only when the filled history disagrees with the raw events, and still
+  allows the one quarter hour per site that the views had already started
+  writing when the fill ran. The session rollups are checked against the
+  session facts in the same way.
+- **A site deletion started before an upgrade finishes after it.** A deletion
+  records its list of tables when it starts; a table dropped by a later
+  migration is now settled as empty instead of being retried forever.
+
+### Removed
+
+- **The hourly rollup tables.** `metrics_1h`, `pages_1h`, `sources_1h`,
+  `geography_1h`, `devices_1h`, `custom_events_1h`, `performance_1h`,
+  `custom_event_samples_1h`, `session_rollups_1h` and `revenue_1h`
+  (ClickHouse migration 0029), with their ClickHouse grants and their entries
+  in site deletion. Nothing has read them since 0.7.0; the daily tables stay.
+
 ## [0.7.0] - 2026-09-18
 
 **Upgrade notes: nothing by hand, but the first start takes longer.**
@@ -22,7 +59,8 @@ views are created counts only the events that arrived after that moment, and
 the first start can log one `history fill backfill-15m failed` with
 `additive_mismatch` (late events reach the new tables but not the frozen
 hourly ones the fill checks against; the history is complete and the line
-does not repeat). The new rollups take up to four rows for every hourly one.
+does not repeat; fixed in 0.8.0). The new rollups take up to four rows for
+every hourly one.
 The new ClickHouse grants arrive with the new image. Details in `SELF-HOSTING.md`, "Upgrades and
 going back".
 
 
@@ -77,7 +77,7 @@ part doing the work: a candidate publishes images under its own tag and sorts
 _above_ the release it is a candidate for, so `git tag --sort=-v:refname` lists
 `v0.1.0-rc.1` before `v0.1.0` and `git describe` would hand you the candidate.
 Dropping every tag with a `-` in it leaves only releases. To take a specific
-one, name it instead: `git checkout v0.7.0`.
+one, name it instead: `git checkout v0.8.0`.
 
 Add `--with-geoip` to that last command to download the country and city
 database in the same pass — see [GeoIP](#geoip). It is the one thing in the
@@ -116,7 +116,7 @@ because you checked out the tag before running it:
 > your version over the baked one, which still wins.
 
 ```sh
-grep OA_IMAGE .env                 # ghcr.io/openlabs-so/openanalytics, v0.7.0
+grep OA_IMAGE .env                 # ghcr.io/openlabs-so/openanalytics, v0.8.0
 docker compose pull
 docker compose up -d
 docker compose logs -f migrate     # schemas, both stores, from empty
@@ -643,7 +643,7 @@ Two things worth knowing before you rely on any of it:
 
 ```sh
 git fetch --tags
-git checkout v0.7.0            # the release you are moving to
+git checkout v0.8.0            # the release you are moving to
 cd infra/selfhost
 ./upgrade.sh                   # tells you what it costs, then does it
 ```
@@ -664,6 +664,31 @@ standing on, takes a snapshot, points `.env` at the new images, pulls them and
 brings everything up. On an architecture with no published images,
 `./upgrade.sh --from-source` builds instead.
 
+**0.7.0 → 0.8.0 asks nothing else of you either**, and it is short:
+
+- **The hourly rollup tables are dropped.** ClickHouse migration 0029 removes
+  the ten `*_1h` tables 0.7.0 stopped writing; nothing had read them since
+  0.7.0 moved every chart to the fifteen-minute rollups. Site deletion stops
+  naming them in the same release. The `*_1d` tables stay.
+- **The history fill checks itself against your raw events.** In 0.7.0 it
+  compared its sums with the frozen hourly tables, so an upgrade with the
+  worker still running could log one `history fill backfill-15m failed` with
+  `additive_mismatch` over history that was complete. It now compares with
+  `events_raw`, which every rollup is built from, so that line no longer
+  appears for that reason — when it does appear, the filled history really
+  disagrees with the raw events, and the report above it says where.
+- **Going back from 0.8.0 is a restore, not an image tag.** 0029 deletes the
+  hourly tables, so the 0.7.0 images would find tables missing. Use
+  `./rollback.sh` to the snapshot `./upgrade.sh` took, as below.
+
+**Skipping 0.7.0 (0.6.0 → 0.8.0) is supported and asks nothing extra.** The
+migrate container applies ClickHouse migrations 0025 through 0029 in one run
+and fills the fifteen-minute rollups from your raw events afterwards, so
+everything 0.7.0 describes below happens too — only the hourly tables are gone
+by the time the fill runs. That is safe because the fill reads `events_raw`
+and checks itself against `events_raw`; no step of it needs an hourly table.
+Read the 0.7.0 notes below for what the fill costs on a large install.
+
 **0.6.0 → 0.7.0 asks nothing else of you either, but it does more while it
 runs**, so it is worth knowing what you are watching:
 
@@ -686,12 +711,9 @@ runs**, so it is worth knowing what you are watching:
 - **If the worker keeps running through the upgrade** — a platform redeploy, or
   `docker compose pull && docker compose up -d` without `./upgrade.sh` — one
   quarter hour can come out short: the one in which the new views were created
-  counts only the events that arrived after that moment. The first start can
-  also log one `history fill backfill-15m failed` with `additive_mismatch`:
-  the fill checks its sums against the hourly tables, and late events that
-  arrive after the switch reach the new tables but not the frozen hourly ones.
-  The history itself is complete, and the next start does not repeat the line.
-  `./upgrade.sh` stops everything first, so it has neither.
+  counts only the events that arrived after that moment. `./upgrade.sh`
+  stops everything first, so it does not have that. (0.7.0 could also log one
+  false `additive_mismatch` here; 0.8.0 no longer does.)
 - **ClickHouse gets new grants**, for the two rollups the worker writes itself.
   They are rendered when its container is created, and the new image tag is
   what recreates it, so `./upgrade.sh` and a platform redeploy deliver them
 
@@ -453,7 +453,7 @@ function buildPersistedEvent(input: BuildPersistedInput): PersistedEvent {
   const page = event.page ? sanitizeUrl(event.page.url, { redactQueryKeys }) : null
   // The site's own hosts are not an acquisition source, and one source has one
   // spelling (ADR-0028). Both rules are applied here, on the way in, because
-  // `referrer_domain` is a rollup grouping key: `sources_1h` has already grouped
+  // `referrer_domain` is a rollup grouping key: `sources_15m` has already grouped
   // by it before any reader exists to repair it.
   const referrer = resolveReferrer(event.referrer, {
     siteDomains: config.allowedDomains,
@@ -466,7 +466,7 @@ function buildPersistedEvent(input: BuildPersistedInput): PersistedEvent {
   // of the channel is the click id the platform put in the landing URL. It is
   // read here, on the way in, for the reason ADR-0028 gives for resolving the
   // referrer here: `referrer_domain` is the rollup grouping key and
-  // `sources_1h` has already grouped by it before any reader exists to repair
+  // `sources_15m` has already grouped by it before any reader exists to repair
   // it. Repairing it at read time would have to be repeated in every future
   // reader — the sources report, the session fact's entry attribution, revenue
   // first/last touch — instead of once.
 
@@ -1,4 +1,5 @@
 import {
+  DELETION_CLICKHOUSE_TARGETS,
   DELETION_REDIS_TARGETS,
   SITE_DELETION_PHASES,
   isSiteDeletionPhase,
@@ -708,6 +709,8 @@ async function objectPurge(context: PhaseContext): Promise<PhaseOutcome> {
  * since ClickHouse queues mutations per table regardless of when they arrive.
  * The job runner's own `limit: 1` is what keeps *deletions* from overlapping.
  */
+const RETAINED_CLICKHOUSE_TARGETS: ReadonlySet<string> = new Set(DELETION_CLICKHOUSE_TARGETS)
+
 async function clickhousePurge(context: PhaseContext): Promise<PhaseOutcome> {
   const maintenance = context.job.resources?.clickhouse
   if (!maintenance) {
@@ -735,6 +738,28 @@ async function clickhousePurge(context: PhaseContext): Promise<PhaseOutcome> {
   for (const target of targets) {
     if (target.phase === 'completed') continue
 
+    // A target the vocabulary no longer names is a table a later migration
+    // dropped — the ten hour tables, ClickHouse 0029 (v0.8.0) — while this
+    // deletion's snapshot, taken at its start, still lists it. The table holds
+    // no row of any site, so there is nothing to purge and nothing a mutation
+    // could be submitted against: ClickHouse would refuse it on every attempt
+    // and the deletion would never finish. Settled as verified-empty, with the
+    // reason, and never submitted.
+    if (!RETAINED_CLICKHOUSE_TARGETS.has(target.target)) {
+      await completeTarget(context, target, {
+        count: 0,
+        mutation_id: null,
+        retired: 'target left the deletion vocabulary: its table was dropped by a migration',
+        verified_at: new Date().toISOString(),
+      })
+      context.job.logger.info('site_deletion_target_retired', {
+        job_id: context.job.job.id,
+        site_id: context.siteId,
+        table: target.target,
+      })
+      continue
+    }
+
     let mutationId = target.mutationId
     // Whether ClickHouse has *reported* this mutation finished. It is not the
     // same question as "are the rows gone", and the difference is what the
 
@@ -84,7 +84,7 @@ const MS_PER_DAY = 86_400_000
 
 // Two grains since ADR-0079 step 4: nothing has read `revenue_1h` since step 3
 // moved every composition to the quarter, so the hour swap was a third of this
-// job's writes for no reader. The table is frozen, not dropped.
+// job's writes for no reader. Migration 0029 dropped the table (v0.8.0).
 const UNITS: readonly RevenueRollupUnit[] = ['15m', '1d']
 
 export interface RevenueRollupDeps {
 
@@ -192,8 +192,8 @@ export async function finalizeSite(
     let rollupSwaps = 0
     // Two grains since ADR-0079 step 4 (migration 0027): the hour rollup was
     // read by nothing after step 3 moved every composition to the quarter, so
-    // writing it was a third of this loop's work for nobody. `session_rollups_1h`
-    // still exists and still holds what it held -- it is simply frozen.
+    // writing it was a third of this loop's work for nobody. Migration 0029
+    // (v0.8.0) then dropped `session_rollups_1h` itself.
     const unitBuckets: Record<SessionRollupUnit, readonly number[]> = {
       '15m': plan.affectedQuarterBucketsMs,
       '1d': plan.affectedDayBucketsMs,
 
@@ -84,11 +84,9 @@ cat >"$TARGET" <<XML
       <grants>
         <query>GRANT INSERT ON analytics.events_raw</query>
         <query>GRANT INSERT ON analytics.session_facts_versions</query>
-        <query>GRANT INSERT ON analytics.session_rollups_1h</query>
         <query>GRANT INSERT ON analytics.session_rollups_1d</query>
         <query>GRANT SELECT ON analytics.events_raw</query>
         <query>GRANT SELECT ON analytics.session_facts_versions</query>
-        <query>GRANT SELECT ON analytics.session_rollups_1h</query>
         <query>GRANT SELECT ON analytics.session_rollups_1d</query>
 
         <!-- Import staging targets the prepare job writes. -->
@@ -111,8 +109,6 @@ cat >"$TARGET" <<XML
         <query>GRANT SELECT ON analytics.revenue_events</query>
         <query>GRANT INSERT ON analytics.revenue_attributions</query>
         <query>GRANT SELECT ON analytics.revenue_attributions</query>
-        <query>GRANT INSERT ON analytics.revenue_1h</query>
-        <query>GRANT SELECT ON analytics.revenue_1h</query>
         <query>GRANT INSERT ON analytics.revenue_1d</query>
         <query>GRANT SELECT ON analytics.revenue_1d</query>
 
 
@@ -0,0 +1,59 @@
+-- ADR-0079 step 4, completed (v0.8.0): the hour rollup TABLES go.
+--
+-- Migration 0027 dropped the eight hour views and kept their tables, for two
+-- reasons it named. Both are gone now:
+--
+--   * the 15m backfill's equality gate compared each family against its hour
+--     twin. It now compares against `events_raw` itself -- the table every view
+--     reads, which is never behind. (The hour twin WAS behind: 0027 froze it,
+--     so any event delivered after 0027 -- a queue backlog drained during the
+--     upgrade -- sat in the 15m rows and not in the reference, and the gate
+--     reported a failed fill over data that was right.)
+--   * the deletion workflow named these tables as targets. It stops naming
+--     them in the same release (`packages/domain/src/deletion.ts`, 44 -> 34
+--     ClickHouse targets), which is the only order that works: a target naming
+--     a table that no longer exists fails every deletion, and the rows a target
+--     would purge leave with the table.
+--
+-- Ten tables: the eight view targets of 0006-0012 and 0021, plus the two swap
+-- targets of 0014 and 0018 that the worker stopped writing in the same step
+-- (`'1h'` left both unit unions). Nothing reads any of them: step 3 moved every
+-- read to the fifteen-minute family, and the compiler has refused a write since
+-- step 4.
+--
+-- The `_1d` family stays. It is read directly for every UTC day and week, and
+-- its views keep firing.
+--
+-- `IF EXISTS` so an install that never had one of them (none should, but a
+-- hand-dropped table is not a reason to stop the stack) passes. An install
+-- skipping 0.7.0 applies 0025-0029 in one run: the 15m family is created by
+-- 0025/0026 and filled from `events_raw` by the migrate container after the
+-- migrations, and nothing in that fill looks at an hour table any more, so
+-- dropping them first is safe.
+--
+-- Reversal, if the hour grain is ever wanted back: this migration deletes
+-- data, so it is not reversed by running an older image. Re-create the tables
+-- and views from 0006-0012, 0014, 0018 and 0021 as a new migration and replay
+-- from `events_raw` (views) and the session facts / revenue facts (swaps), all
+-- of which are kept. A self-hosted install restores the pre-upgrade backup
+-- instead (`./rollback.sh`).
+
+DROP TABLE IF EXISTS metrics_1h;
+
+DROP TABLE IF EXISTS pages_1h;
+
+DROP TABLE IF EXISTS sources_1h;
+
+DROP TABLE IF EXISTS geography_1h;
+
+DROP TABLE IF EXISTS devices_1h;
+
+DROP TABLE IF EXISTS custom_events_1h;
+
+DROP TABLE IF EXISTS performance_1h;
+
+DROP TABLE IF EXISTS custom_event_samples_1h;
+
+DROP TABLE IF EXISTS session_rollups_1h;
+
+DROP TABLE IF EXISTS revenue_1h;