diff --git a/platform/velero/helmrelease.yaml b/platform/velero/helmrelease.yaml
index 975d0d4..27a794b 100644
--- a/platform/velero/helmrelease.yaml
+++ b/platform/velero/helmrelease.yaml
@@ -198,6 +198,26 @@ spec:
           includedNamespaces:
             - monitoring
             - unifi
+    # --- SCRAPE THE BACKUP CONTROLLER, or its failures are silent (added 2026-09-12) ------------
+    # platform/monitoring/alerts.yaml already ships VeleroBackupFailure (critical),
+    # VeleroBackupPartialFailure and VeleroNoRecentBackup — and NONE of them could ever fire,
+    # because the chart defaults `metrics.serviceMonitor.enabled: false` and no ServiceMonitor
+    # existed in ns velero (verified live on prod, 2026-09-12: `get servicemonitor -n velero` →
+    # no resources). The series velero_backup_failure_total / velero_backup_last_successful_timestamp
+    # were never scraped, so a nightly backup could fail — or stop running — indefinitely with no
+    # alert. That is the precise failure mode R-STATE-03 exists to prevent, so the scrape is part of
+    # the backup path, not an observability nice-to-have.
+    # The chart gates these on BOTH `enabled` and capability detection of monitoring.coreos.com/v1
+    # (verified: `helm template` emits neither object without --api-versions, and emits both with
+    # it), so `enabled: true` is required and sufficient — helm-controller supplies real capabilities
+    # from the API server. No additionalLabels needed: platform/monitoring sets
+    # serviceMonitorSelectorNilUsesHelmValues / podMonitorSelectorNilUsesHelmValues false, so
+    # Prometheus selects every ServiceMonitor/PodMonitor regardless of labels.
+    metrics:
+      serviceMonitor:
+        enabled: true            # velero server: backup/restore success+failure counters
+      nodeAgentPodMonitor:
+        enabled: true            # node-agent: kopia FSB (PodVolumeBackup) progress + failures
     # Modest home-dev footprint (mirror the other platform components).
     resources:
       requests: