@@ -170,7 +170,14 @@ wait_sts_ready() {
         fi
         if [[ $elapsed -ge $timeout ]]; then
             log_error "Timeout waiting for StatefulSet/$name to become ready"
-            kubectl -n "$NAMESPACE" get pods -l "clickhouse.altinity.com/chi=${name#chi-}" >&2 2>/dev/null || true
+            # A StatefulSet names its Pods "<sts>-N", so ask for the first
+            # replica by name instead of guessing an operator label — and let
+            # both streams through, since the point of this branch is to say
+            # WHY the Pod never came up. Events carry the reason a Pod is
+            # Pending (unschedulable, missing PVC, image pull) that neither the
+            # Pod nor the StatefulSet status spells out.
+            kubectl -n "$NAMESPACE" get statefulset.apps "$name" -o wide >&2 || true
+            kubectl -n "$NAMESPACE" describe pod "${name}-0" >&2 || true
             return 1
         fi
         sleep 5
 
@@ -160,11 +160,19 @@ spec:
               cpu: 200m
               memory: 128Mi
           securityContext:
-            # Pod runs apk add at startup; that needs root. Other fields stay
-            # locked down (no privilege escalation, no extra caps, default
-            # seccomp profile). Tenants that enforce PSA "restricted" should
-            # swap this image for one with curl+jq pre-baked and re-enable
-            # runAsNonRoot on the strategy CR.
+            # Same field set as the platform's cozy-default-altinity strategy
+            # (packages/system/backupstrategy-controller/templates/strategy-altinity-default.yaml):
+            # no privilege escalation, all caps dropped, default seccomp
+            # profile, and runAsNonRoot deliberately left unset rather than
+            # false — the Pod only runs curl and jq, and neither the platform
+            # strategy nor this one pins a UID.
+            #
+            # On the default path there is no `apk add` to need root: the image
+            # above is the platform's, with curl+jq already baked in. Only the
+            # alpine:3.19 fallback (taken when cozy-default-altinity is absent)
+            # installs packages at startup, and that is the one case where a
+            # cluster enforcing PSA "restricted" has to supply its own image
+            # with the tools pre-baked.
             allowPrivilegeEscalation: false
             capabilities:
               drop: ["ALL"]
 
@@ -28,11 +28,11 @@ EOF
 
 log_substep "Waiting for bucket HelmRelease to be Ready..."
 wait_hr_ready "bucket-${BUCKET_NAME}" 300
-kubectl -n "$NAMESPACE" wait bucketclaims.objectstorage.k8s.io "bucket-${BUCKET_NAME}" --for=jsonpath='{.status.bucketReady}'=true --timeout=300s
+kubectl -n "$NAMESPACE" wait bucketclaims.objectstorage.k8s.io "bucket-${BUCKET_NAME}" --for=jsonpath='{.status.bucketReady}'=true --timeout=180s
 # Cozystack's bucket app provisions a BucketAccess named "<bucket-name>-backup"
 # (the "-backup" suffix is the BucketAccessClass name); the BucketInfo Secret
 # carries the same name.
-kubectl -n "$NAMESPACE" wait bucketaccesses.objectstorage.k8s.io "bucket-${BUCKET_NAME}-backup" --for=jsonpath='{.status.accessGranted}'=true --timeout=300s
+kubectl -n "$NAMESPACE" wait bucketaccesses.objectstorage.k8s.io "bucket-${BUCKET_NAME}-backup" --for=jsonpath='{.status.accessGranted}'=true --timeout=180s
 
 log_substep "Reading bucket coordinates from BucketInfo Secret..."
 TMP=$(mktemp)
 
@@ -27,7 +27,7 @@ log_substep "Waiting for BackupJob to Succeed (this triggers clickhouse-backup c
 # `kubectl wait --for=jsonpath='{.status.phase}'=Running` would time out even
 # though the BackupJob actually finished. wait_for_field already polls until
 # the terminal phase, which covers both the slow and the fast path.
-wait_for_field backupjob "$BACKUPJOB_NAME" '{.status.phase}' Succeeded "$NAMESPACE" 600 Failed
+wait_for_field backupjob "$BACKUPJOB_NAME" '{.status.phase}' Succeeded "$NAMESPACE" 480 Failed
 
 backup_ref=$(kubectl -n "$NAMESPACE" get backupjob "$BACKUPJOB_NAME" -o jsonpath='{.status.backupRef.name}')
 [[ -n "$backup_ref" ]] || { log_error "BackupJob succeeded but BackupRef is empty"; exit 1; }
 
@@ -24,7 +24,7 @@ spec:
 EOF
 
 log_substep "Waiting for in-place RestoreJob to Succeed..."
-wait_for_field restorejob "$RESTOREJOB_INPLACE_NAME" '{.status.phase}' Succeeded "$NAMESPACE" 600 Failed
+wait_for_field restorejob "$RESTOREJOB_INPLACE_NAME" '{.status.phase}' Succeeded "$NAMESPACE" 480 Failed
 
 log_substep "Verifying sentinel data is restored..."
 count=$(clickhouse_query "$CLICKHOUSE_NAME" "SELECT count() FROM default.sentinel" | tr -d '[:space:]')
 
@@ -86,7 +86,7 @@ spec:
 EOF
 
 log_substep "Waiting for to-copy RestoreJob to Succeed..."
-wait_for_field restorejob "$RESTOREJOB_TOCOPY_NAME" '{.status.phase}' Succeeded "$NAMESPACE" 600 Failed
+wait_for_field restorejob "$RESTOREJOB_TOCOPY_NAME" '{.status.phase}' Succeeded "$NAMESPACE" 480 Failed
 
 log_substep "Verifying sentinel data exists on the copy..."
 count=$(clickhouse_query "$CLICKHOUSE_RESTORE_NAME" "SELECT count() FROM default.sentinel" | tr -d '[:space:]')
 
@@ -300,22 +300,30 @@ spec:
           NAMESPACE="$NAMESPACE" examples/backups/clickhouse/cleanup.sh
         check:
           ($error == null): true
-    # Budget: the op timeout must exceed the sum of the inner waits it contains,
-    # per the rule .chainsaw.yaml states for its own catch scripts — otherwise
-    # Chainsaw SIGKILLs the script part-way and the failure arrives with no
-    # diagnostics at all, which is strictly worse than an inner wait timing out
-    # and reporting which resource stalled. The harness's inner budgets sum to
-    # 3900s (03: 300 HR + 300 claim + 300 access; 04: 300 HR + 300 STS; 05: 600
-    # BackupJob; 06: 600 RestoreJob; 07: 300 HR + 300 STS + 600 RestoreJob), so
-    # 65m clears it with room for the SQL and apply steps between them
-    # (convention 6: justified in-line).
+    # Budget: the op timeout must be strictly ABOVE the sum of the inner waits,
+    # per docs/agents/e2e-testing.md — let an inner wait be what fires, because
+    # it names the resource that stalled, whereas hitting the op timeout means
+    # Chainsaw SIGKILLs the script and the failure arrives with no diagnostics
+    # at all (.chainsaw.yaml calls that "strictly worse").
     #
-    # Reaching that ceiling takes a pathological hang: every wait here fails
+    # Inner budgets, sized against what CI actually takes rather than guessed
+    # generously — the whole bucket suite completes in ~37s and a backup-enabled
+    # ClickHouse plus Keeper reaches Ready in ~98s (measured on run 30353894332):
+    #   03  660s = 300 bucket HR + 180 claim + 180 access
+    #   04  600s = 300 HR + 300 StatefulSet
+    #   05  480s = BackupJob to Succeeded
+    #   06  480s = in-place RestoreJob
+    #   07 1080s = 300 HR + 300 StatefulSet + 480 to-copy RestoreJob
+    #        sum = 3300s (55m)
+    # 60m therefore leaves ~5m of headroom for the kubectl apply / exec SQL
+    # calls interleaved between those waits (convention 6: justified in-line).
+    #
+    # Reaching the ceiling at all takes a pathological hang: every wait fails
     # fast on a terminal state — wait_for_field bails on phase=Failed and
     # wait_hr_ready on Stalled=True — so a genuinely broken backup reports in
     # seconds. The happy path is minutes.
     - script:
-        timeout: 65m
+        timeout: 60m
         content: |
           set -eu
           cd ../../..
 
@@ -1,4 +1,4 @@
-# Backup-enabled ClickHouse for the clickhouse-backup-1-contracts Test.
+# Backup-enabled ClickHouse for the clickhouse-1-backup-contracts Test.
 #
 # A single shard / single replica keeps CI cost close to the plain
 # `clickhouse` suite while still rendering the `clickhouse-backup` sidecar
@@ -11,7 +11,7 @@
 # platform useSystemBucket flow marks the S3 secret keys optional so the Pod
 # starts before any bucket is projected). So the Pod becomes Ready and the
 # chart<->strategy contract is assertable with no reachable object store. The
-# real S3 backup/restore round-trip lives in clickhouse-backup-2-roundtrip,
+# real S3 backup/restore round-trip lives in clickhouse-2-backup-roundtrip,
 # which runs in tenant-root against the in-cluster SeaweedFS.
 #
 # backup.endpointCA is deliberately left unset: this Test never reaches S3, and
 
@@ -92,11 +92,15 @@ while IFS= read -r file; do
       trigger_any=1
       continue ;;
     examples/backups/*/*)
-      # The etcd and postgres backup round-trip tests execute the example
-      # scripts under examples/backups/<app>/ as their harness, so an edit
-      # there must run that app's suite. A dir with no matching suite is a
-      # docs-only demo and stays ignored (adding it to selected_apps would
-      # empty the final intersection and trip the full-suite safety net).
+      # The etcd, postgres, mariadb and clickhouse backup round-trip tests
+      # execute the example scripts under examples/backups/<app>/ as their
+      # harness, so an edit there must run that app's suite. This mapping is
+      # also why a round-trip Test belongs in its app's own suite dir: put it
+      # in a dir whose name does not match examples/backups/<app>/ and an edit
+      # to the harness selects a suite that cannot exercise it. A dir with no
+      # matching suite is a docs-only demo and stays ignored (adding it to
+      # selected_apps would empty the final intersection and trip the
+      # full-suite safety net).
       app=$(echo "$file" | sed -nE 's,^examples/backups/([^/]+)/.*,\1,p')
       if echo "$all_apps" | grep -Fxq "$app"; then
         selected_apps="$selected_apps $app"
 
@@ -99,21 +99,6 @@
     echo "$output" | grep -q "kubernetes-oidc-customconfig"
 }
 
-@test "clickhouse backup harness edit selects the suite that runs it" {
-    # The clickhouse suite dir holds the backup round-trip Test that executes
-    # examples/backups/clickhouse/run-all.sh, so an edit to that harness has to
-    # select `clickhouse` — the suite is what runs the scripts. Keeping the
-    # round-trip in the app's own suite dir (rather than a clickhouse-backup one)
-    # is what makes the examples/backups/<app> -> <app> mapping line up; this
-    # locks that alignment for clickhouse specifically.
-    tmp=$(mktemp -d)
-    trap 'rm -rf "$tmp"' EXIT
-    cp -r packages/core/platform/sources "$tmp/sources"
-    echo "examples/backups/clickhouse/run-all.sh" > "$tmp/diff"
-    output=$(hack/select-e2e.sh "$tmp/diff" "$tmp/sources")
-    [ "$output" = "clickhouse" ]
-}
-
 @test "dashboards-only diff selects nothing (path is plural)" {
     tmp=$(mktemp -d)
     trap 'rm -rf "$tmp"' EXIT
Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-# Backup-enabled ClickHouse for the clickhouse-backup-1-contracts Test.`
	`1`	`+# Backup-enabled ClickHouse for the clickhouse-1-backup-contracts Test.`
`2`	`2`	`#`
`3`	`3`	`# A single shard / single replica keeps CI cost close to the plain`
`4`	`4`	# `clickhouse` suite while still rendering the `clickhouse-backup` sidecar
`@@ -11,7 +11,7 @@`
`11`	`11`	`# platform useSystemBucket flow marks the S3 secret keys optional so the Pod`
`12`	`12`	`# starts before any bucket is projected). So the Pod becomes Ready and the`
`13`	`13`	`# chart<->strategy contract is assertable with no reachable object store. The`
`14`		`-# real S3 backup/restore round-trip lives in clickhouse-backup-2-roundtrip,`
	`14`	`+# real S3 backup/restore round-trip lives in clickhouse-2-backup-roundtrip,`
`15`	`15`	`# which runs in tenant-root against the in-cluster SeaweedFS.`
`16`	`16`	`#`
`17`	`17`	`# backup.endpointCA is deliberately left unset: this Test never reaches S3, and`