diff --git a/nextcloud/roles/nextcloud/tasks/main.yaml b/nextcloud/roles/nextcloud/tasks/main.yaml
index 64add15..14cc50c 100644
--- a/nextcloud/roles/nextcloud/tasks/main.yaml
+++ b/nextcloud/roles/nextcloud/tasks/main.yaml
@@ -90,9 +90,26 @@
 
 # Quadlet honours [Install] WantedBy= when it generates the unit, so
 # `systemctl --user enable` is neither needed nor possible on a generated unit.
-- name: Verify Nextcloud is running
+#
+# This waits rather than checking once. `systemctl start` returns while the unit
+# is still `activating`: the start job is done before conmon has signalled
+# readiness, and `is-active` exits 3 for `activating` — so a single check reports
+# a healthy start as a failure. That is exactly what happened on this play's
+# first real run, which stopped here with `stdout: "activating"`.
+#
+# It retries only through that transition. A unit that is `failed` or `inactive`
+# is not going to become `active` by waiting, so it fails immediately with the
+# state in the message instead of five minutes later. The case that genuinely
+# needs patience — the app answering yet — is the readiness gate below, which has
+# the richer rescue.
+- name: Wait for the Nextcloud unit to become active
   ansible.builtin.command: "systemctl --user is-active {{ unit_name }}"
   register: nextcloud_active
+  until: >-
+    nextcloud_active.stdout == 'active'
+    or nextcloud_active.stdout not in ['activating', 'reloading']
+  retries: 60
+  delay: 5
   changed_when: false
   failed_when: nextcloud_active.stdout != 'active'