Site unavailable

Check the Site state

Open the Site and confirm whether it is RUNNING, in maintenance, degraded or waiting on another operation.

Check Health and Convergence

Health tells you whether the workload is serving correctly. Convergence tells you whether Control-managed state matches what is configured. A Convergence repair does not always mean the Site itself is down.

Check runtime evidence

Review the runtime state and the Site's error logs. For proxied runtimes, make sure the application itself starts and listens as expected. For PHP, check application/PHP errors. For containers, check the container/service state exposed by the Site.

Check ingress

Verify DNS, HTTP/HTTPS selection and certificate state. If HTTPS is the only failing layer, keep the Site working over HTTP while you correct TLS rather than recreating the application.

If a CDN or reverse proxy is enabled before origin HTTPS is ready, an early HTTPS request may fail while the Site is still healthy over HTTP. Current Control releases isolate the pending hostname on origin port 443 so it cannot be served by another managed Site while certificate activation is still in progress.

Failed provisioning after the workload appeared to start

If Site creation reaches runtime and ingress checks but still reports failed provisioning, review the failure reason and current Site state before retrying. Control verifies current workload health after a short settle window; a genuine current runtime or ingress failure still causes rollback, while an older transient status sample does not.

Site Settings reports filesystem_scan_incomplete

Current Control separates filesystem-observation completeness from Site Settings verification. A large tree can exceed the limited filesystem scan budget without proving that an ingress, PHP, WAF, redirect or resilience change failed. Review filesystem Attention separately; retry the settings operation only when the operation itself reports managed-configuration or workload drift.