@@ -543,7 +543,7 @@ jobs:
     # Covers a green full suite. It does not cover a tenant-Kubernetes suite
     # running into its node-join deadline, so a red there can end as a
     # cancelled job. Held to one figure across every lane that runs the suite.
-    timeout-minutes: 215
+    timeout-minutes: 255
     permissions:
       contents: read
       packages: read
 
@@ -137,7 +137,7 @@ jobs:
     # Covers a green full suite. It does not cover a tenant-Kubernetes suite
     # running into its node-join deadline, so a red there can end as a
     # cancelled job. Held to one figure across every lane that runs the suite.
-    timeout-minutes: 215
+    timeout-minutes: 255
     permissions:
       contents: read
       checks: write # Breakpoint action updates its dedicated "Breakpoint Open" Check Run.
@@ -292,7 +292,7 @@ jobs:
       # collect-report packages cozyreport plus per-failed-test crust-gather
       # snapshots captured before Chainsaw cleanup.
       #
-      # A ceiling of its own, not the job's 215 minutes. `Upload cozyreport.tgz`
+      # A ceiling of its own, not the job's 255 minutes. `Upload cozyreport.tgz`
       # is the next step and the collector writes its tarball at the very end of
       # its run, so a read that never returns spends what is left of the job
       # budget, the job is cancelled, and the upload never runs -- the artifact
 
@@ -250,7 +250,7 @@ jobs:
     # Covers a green full suite. It does not cover a tenant-Kubernetes suite
     # running into its node-join deadline, so a red there can end as a
     # cancelled job. Held to one figure across every lane that runs the suite.
-    timeout-minutes: 215
+    timeout-minutes: 255
     permissions:
       contents: read
       packages: read
@@ -385,7 +385,7 @@ jobs:
           path: _out/chainsaw-report.xml
           if-no-files-found: ignore
 
-      # A ceiling of its own, not the job's 215 minutes. `Upload cozyreport.tgz`
+      # A ceiling of its own, not the job's 255 minutes. `Upload cozyreport.tgz`
       # is the next step and the collector writes its tarball at the very end of
       # its run, so a read that never returns spends what is left of the job
       # budget, the job is cancelled, and the upload never runs -- the artifact
 
@@ -1053,7 +1053,7 @@ jobs:
     # Covers a green full suite. It does not cover a tenant-Kubernetes suite
     # running into its node-join deadline, so a red there can end as a
     # cancelled job. Held to one figure across every lane that runs the suite.
-    timeout-minutes: 215
+    timeout-minutes: 255
     permissions:
       contents: read
       packages: read
@@ -1324,7 +1324,7 @@ jobs:
 
       # ▸ Collect debug information (always runs)
       #
-      #   A ceiling of its own, not the job's 215 minutes. `Upload
+      #   A ceiling of its own, not the job's 255 minutes. `Upload
       #   cozyreport.tgz` is the next step and the collector writes its tarball
       #   at the very end of its run, so a read that never returns spends what
       #   is left of the job budget, the job is cancelled, and the upload never
@@ -1335,7 +1335,7 @@ jobs:
       #   30 minutes is measured against the step: it takes 3-42s across sampled
       #   runs, on failed e2e jobs as well as green ones. It RESERVES nothing --
       #   `timeout-minutes` caps a step, it does not carve budget out of the job,
-      #   so a suite that has already burned 210 of the 215 leaves this step five
+      #   so a suite that has already burned 250 of the 255 leaves this step five
       #   minutes and the upload is cancelled with everything else. What the cap
       #   buys is that a hung read cannot be the reason.
       #   `continue-on-error` because the ceiling must not change what the job
 
@@ -241,11 +241,11 @@ A HelmRelease install waits through kstatus unless the ApplicationDefinition car
 
 The first floor is the app's own first boot. For a chart that sets `startupProbe` it is `initialDelaySeconds + (failureThreshold - 1) * periodSeconds`; for a chart that does not, it is whatever its operator needs, and only a measurement will say. mariadb is the case in this tree where this floor is real rather than nominal: its chart grants a 310s startup budget, so a wait that fails earlier fails a boot the probe was still willing to wait for.
 
-The second floor is the release's own install timeout, and it is usually the binding one. Where to read it depends on who created the release, and getting this wrong under-budgets rather than over-budgets. For a release cozystack-api generated from an ApplicationDefinition the default is 10m (`pkg/cmd/server/start.go`), overridden per definition by `release.cozystack.io/helm-install-timeout` — `kubernetes-rd` at 20m, `kubernetes-nodes-rd`, `tenant-rd` and `monitoring-rd` at 15m, `kafka-rd` at 7h, a floor no suite clears inside the E2E job's 215-minute cap; the first two also disable the wait, so for `kubernetes` the override bounds its blocking post-install hook rather than a kstatus poll, and `kubernetes-nodes`, which renders no post-install hook, has nothing in its install for the override to bound. For a HelmRelease an app chart renders itself there is no ApplicationDefinition to read and that default never applies: the floor is the `spec.install.timeout` on the template that renders it, which takes precedence over its `spec.timeout`, and where a template sets neither, helm-controller's own documented default of 5m applies instead. There is deliberately no count of that population here. Read the value off the template you are waiting on: they range from 5m to 30m, they are spread across `packages/apps`, `packages/extra` and `packages/system`, and a release carrying `spec.kubeConfig` installs into a tenant cluster and is not one of these at all. A number in this sentence would be an obligation to revisit it whenever a template is added, and its three qualifiers are each easy to drop from a recursive grep. The nested `<name>-system` releases the app charts wrap their workloads in are all of this second kind. A HelmRelease that cozystack-operator builds for a `Package` is a third kind: its `spec.install.timeout` comes from the operator's `--helmrelease-install-timeout`, 10m unless `cozystackOperator.helmReleaseInstallTimeout` in the installer chart overrides it. At or below whichever floor applies, a failed install is reported as a bare assert timeout, because the release has not yet recorded why it failed.
+The second floor is the release's own install timeout, and it is usually the binding one. Where to read it depends on who created the release, and getting this wrong under-budgets rather than over-budgets. For a release cozystack-api generated from an ApplicationDefinition the default is 10m (`pkg/cmd/server/start.go`), overridden per definition by `release.cozystack.io/helm-install-timeout` — `kubernetes-rd` at 20m, `kubernetes-nodes-rd`, `tenant-rd` and `monitoring-rd` at 15m, `kafka-rd` at 7h, a floor no suite clears inside the E2E job's 255-minute cap; the first two also disable the wait, so for `kubernetes` the override bounds its blocking post-install hook rather than a kstatus poll, and `kubernetes-nodes`, which renders no post-install hook, has nothing in its install for the override to bound. For a HelmRelease an app chart renders itself there is no ApplicationDefinition to read and that default never applies: the floor is the `spec.install.timeout` on the template that renders it, which takes precedence over its `spec.timeout`, and where a template sets neither, helm-controller's own documented default of 5m applies instead. There is deliberately no count of that population here. Read the value off the template you are waiting on: they range from 5m to 30m, they are spread across `packages/apps`, `packages/extra` and `packages/system`, and a release carrying `spec.kubeConfig` installs into a tenant cluster and is not one of these at all. A number in this sentence would be an obligation to revisit it whenever a template is added, and its three qualifiers are each easy to drop from a recursive grep. The nested `<name>-system` releases the app charts wrap their workloads in are all of this second kind. A HelmRelease that cozystack-operator builds for a `Package` is a third kind: its `spec.install.timeout` comes from the operator's `--helmrelease-install-timeout`, 10m unless `cozystackOperator.helmReleaseInstallTimeout` in the installer chart overrides it. At or below whichever floor applies, a failed install is reported as a bare assert timeout, because the release has not yet recorded why it failed.
 
 What holds the install open is anything in the rendered manifests kstatus reports InProgress, which is wider than a `Ready` condition. kstatus carries built-in rules for a list of kinds — the workloads, but also `Service`, `Pod`, `PersistentVolumeClaim` and `CustomResourceDefinition` — and falls through to reading `Ready` only for kinds it has no rule for. Read that list rather than recalling it: `legacyTypes` in `pkg/kstatus/status/core.go` of `fluxcd/cli-utils`, at whatever version the helm-controller image in `internal/fluxinstall/manifests/fluxcd.yaml` was built against — nothing in this repository vendors it, so there is no local copy to open and the version has to come from that image. It does not divide the way intuition suggests, because `Secret`, `ConfigMap` and `batch/CronJob` are in the table and map to always-ready, so being in it is not the same as gating on it. The practical consequence is that "renders no CR publishing `Ready`" does not exempt a release, and `tcp-balancer` and `vpn` show why: each renders a `WorkloadMonitor`, whose status type declares no `conditions` at all, so kstatus falls past the `Ready` fallback and reads that CR as Current — and then gates the install on the Deployment beside it through a built-in rule. The CR is present and contributes nothing; the workload is what holds the install open.
 
-Every mistake in this derivation under-budgets, which is the harmful direction — but the floor is not free either, because a wait that must exceed its release's install timeout means a genuinely failing suite burns that long before it says so, and `.chainsaw.yaml` already warns about diagnostics eating the job's own 215m — for scale, the timeouts written on the mariadb suite's own steps come to 120m of that, before the defaults its untimed steps inherit from `.chainsaw.yaml`, and a job cancelled at the cap loses both its log and `cozyreport.tgz`. Raise a suite when a failed install there needs to say why; leave one alone when the diagnosis is not worth ten minutes added to every red run in that suite. That is the trade, and it is per suite — "only the ones kstatus polls" is not a filter, because almost everything polls. Two suites are worth reading before writing a new wait, and deliberately not as a list of every wait and its floor: a hand-written list of them is incomplete in a way its author cannot see, and goes stale without saying so — a `grep` for the call misses the invocations split across lines, and reading for it by eye misses the single-release waits among the `--all` ones. Enumerate with `grep -rnE 'kubectl +wait.*(^|[^[:alnum:]])hr([^[:alnum:]]|$)' hack/` and the chainsaw asserts on `kind: HelmRelease`, not from memory and not from here. mariadb's 11m in `hack/e2e-chainsaw/mariadb/chainsaw-test.yaml` is the worked example of the derivation above. harbor's two asserts show why one literal cannot serve a whole suite: `harbor-test` is generated and clears its 600s floor at 11m, while `harbor-test-system` is rendered by the app chart with a `spec.timeout` of 15m and needs 16m.
+Every mistake in this derivation under-budgets, which is the harmful direction — but the floor is not free either, because a wait that must exceed its release's install timeout means a genuinely failing suite burns that long before it says so, and `.chainsaw.yaml` already warns about diagnostics eating the job's own 255m — for scale, the timeouts written on the mariadb suite's own steps come to 120m of that, before the defaults its untimed steps inherit from `.chainsaw.yaml`, and a job cancelled at the cap loses both its log and `cozyreport.tgz`. Raise a suite when a failed install there needs to say why; leave one alone when the diagnosis is not worth ten minutes added to every red run in that suite. That is the trade, and it is per suite — "only the ones kstatus polls" is not a filter, because almost everything polls. Two suites are worth reading before writing a new wait, and deliberately not as a list of every wait and its floor: a hand-written list of them is incomplete in a way its author cannot see, and goes stale without saying so — a `grep` for the call misses the invocations split across lines, and reading for it by eye misses the single-release waits among the `--all` ones. Enumerate with `grep -rnE 'kubectl +wait.*(^|[^[:alnum:]])hr([^[:alnum:]]|$)' hack/` and the chainsaw asserts on `kind: HelmRelease`, not from memory and not from here. mariadb's 11m in `hack/e2e-chainsaw/mariadb/chainsaw-test.yaml` is the worked example of the derivation above. harbor's two asserts show why one literal cannot serve a whole suite: `harbor-test` is generated and clears its 600s floor at 11m, while `harbor-test-system` is rendered by the app chart with a `spec.timeout` of 15m and needs 16m.
 
 Two things this derivation does not give you. Readiness *may* span a first boot rather than always doing so — a poll landing before the operator's first status write reads a condition-less resource as Current and can end the wait early, which is why a suite keeps an endpoint assert after the HR-Ready one rather than treating it as redundant. And a number copied from a neighbouring suite says nothing about the release you are waiting on, even where it clears the neighbour's floor: the floor depends on who rendered the release, and kafka's assert sits under its own on purpose. Scan `hack/e2e-chainsaw/*/chainsaw-test.yaml` for HR-Ready asserts and hold each against its own release's floor plus the start margin; the result is left to that scan rather than written out here, because a list of them goes stale silently while the scan does not. Chainsaw asserts are not the whole surface: `wait_hr_ready` calls under `examples/backups/` carry the same floor, not all of them from a `run-all.sh` and not all of them with a literal budget — a call that passes none takes the helper's own default, which a grep for the number misses — so scan both places. Derive the budget from the release you are waiting on.
 
 
@@ -121,7 +121,7 @@
 # the number; do not expect to find it written here.
 #
 # TWO ceilings sit outside it, and they fail differently. The job is capped at
-# `timeout-minutes: 215`, and reaching that cancels every step still to come --
+# `timeout-minutes: 255`, and reaching that cancels every step still to come --
 # the artifact upload among them. The step running this script is capped at 30 of
 # its own, and reaching THAT ends only this step: the uploads after it still run,
 # and `continue-on-error` on that step keeps the overrun out of the job's result,
 
@@ -208,7 +208,7 @@ _cozy_on_exit() {
       # capture would read as a complete one listing fewer crash-loops than
       # actually occurred. This handler's whole worst case is ~1350s (330 + 390
       # + 630, each leg including its 30s kill grace) against a job capped at
-      # 215 minutes with no per-step timeout —
+      # 255 minutes with no per-step timeout —
       # deliberate, for the same reason recorded in hack/e2e-chainsaw/.chainsaw.yaml:
       # a bounded, honest wait beats a kill that collects nothing.
       if [ "$_prev_rc" -ne 0 ]; then
 
@@ -66,14 +66,14 @@ spec:
   # script: it SIGKILLs the shell alone, orphaned children hold the pipe open,
   # and the op overruns (#4268 measured 606s under a 300s ceiling), so the
   # nominal ~5m was a figure a busy catch could exceed, not a cap. Tests run
-  # sequentially, and the E2E job is capped at 215 timeout-minutes. A cascade
+  # sequentially, and the E2E job is capped at 255 timeout-minutes. A cascade
   # reddening many suites can therefore spend a large share of the job in
   # diagnostics. That is deliberate — the old ceiling
   # bought its speed by collecting nothing at all — and it is bounded: both legs
   # only approach their ceilings on a genuinely degraded cluster, a systemic
   # failure usually reds the install gate and skips the E2E step entirely, and
   # the report-upload steps are `if: always()`. That last point does NOT extend
-  # to a job timeout: a 215-minute cap ends the job `cancelled`, and the ~4m48s
+  # to a job timeout: a 255-minute cap ends the job `cancelled`, and the ~4m48s
   # grace window is consumed by the earlier `Collect report` step, so both
   # cozyreport.tgz and the job log are lost (measured on runs 29557003429 and
   # 29568562337). If this ever does start truncating runs, bound the number of
Original file line number	Diff line number	Diff line change
`@@ -121,7 +121,7 @@`
`121`	`121`	`# the number; do not expect to find it written here.`
`122`	`122`	`#`
`123`	`123`	`# TWO ceilings sit outside it, and they fail differently. The job is capped at`
`124`		-# `timeout-minutes: 215`, and reaching that cancels every step still to come --
	`124`	+# `timeout-minutes: 255`, and reaching that cancels every step still to come --
`125`	`125`	`# the artifact upload among them. The step running this script is capped at 30 of`
`126`	`126`	`# its own, and reaching THAT ends only this step: the uploads after it still run,`
`127`	`127`	# and `continue-on-error` on that step keeps the overrun out of the job's result,