If Coolify appears down, first identify what failed: the hosted dashboard, your self-hosted dashboard, or an application deployed through Coolify. Those are different systems. A public status page cannot inspect your own server.
Start with Coolify community reports. ServiceAlert currently shows community evidence for Coolify, not an official health verdict for every installation. Compare the report time and symptom with what you see.
Find the failing layer
| What you cannot reach | Check first | Useful distinction |
|---|---|---|
| Hosted Coolify dashboard | Your connection, sign-in result and provider support | A dashboard failure does not establish that deployed applications stopped |
| Your self-hosted dashboard | Server reachability, dashboard container and proxy logs | A private deployment can fail while other Coolify users are unaffected |
| One deployed application | Application logs, internal port and health check | A working dashboard does not prove that application is ready |
| Several applications on one server | Shared proxy, DNS and host resources | A common server dependency can explain several failures |
If the dashboard is inaccessible
Record whether you normally use a custom domain or an administrator-managed direct connection. Coolify's dashboard troubleshooting guide separates proxy/domain access from container and host failures. Ask the server owner to compare those paths using the existing protected administration access.
Inspect container state and recent proxy errors before restarting anything. A restart may interrupt other workloads and erase useful transient evidence. Preserve the exact error and its UTC time. Avoid exposing an administration port to the public internet merely to diagnose a dashboard problem.
If an application returns an error
For a 502 response, compare the application's listening port with its configured internal port and inspect its startup logs. For a 503 or a “No available server” response, check whether the proxy has a healthy application target. The vendor's 502 guide and 503 guide explain these separate failure paths.
A running container is not necessarily ready to receive requests. Coolify's health-check documentation explains how checks run inside the container and how unhealthy targets affect Traefik routing. Compare the configured path, internal port and available HTTP client with the application you actually deployed. Compose applications define checks in their Compose configuration or Dockerfile.
Escalate with useful evidence
Share the affected layer, error text, start time, recent deployment changes and the checks already completed. Send private hostnames, configuration and logs through your team's support channel. A report that says “one application returns 503 after deployment; dashboard works” is much more actionable than “Coolify is down.”
Follow Coolify status changes or check related provider incidents. A follow does not monitor your private dashboard or application; add your own uptime monitor for that system.