A site that is down is not one problem. It is a dozen different problems that all look identical from a browser, and the fastest route to the right one is a short sequence of checks that eliminate whole categories at a time.
Work through these in order. Each answers a question that changes what you check next.
First: is it down for everyone
Before anything else, rule out the possibility that the site is fine.
Open it in a private window on a different network. A phone on mobile data is ideal, because it shares nothing with your computer.
If it loads there, the site is up and your access is the problem: browser cache, a stale DNS entry on your machine, or your own address blocked by a security tool after too many failed logins. That last one is common and is fixed from your host's control panel rather than by anything on the site.
Read the error, because it names the layer
Different failures produce different errors, and the difference is the most useful information you have.
Server not found / DNS error. The domain is not resolving. This is DNS or the registration, not the server.
Connection timed out. The domain resolves and nothing answers. The server is down, or a firewall is blocking you.
500 Internal Server Error. The server is running and your application broke. This is the most common one and the most fixable.
503 Service Unavailable. Temporarily overloaded, or in maintenance mode.
Browser security warning. The site is up. The certificate expired or does not match. There is more in SSL troubleshooting.
A blank white page. PHP hit a fatal error with error display off. This is a 500 wearing a disguise.
If it is DNS
Check the domain has not expired. This sounds obvious and it is the cause often enough to check first, because an expired domain produces exactly this symptom and nothing on the server is wrong.
Then confirm the records:
dig example.com A +short dig example.com NS +short
Nothing returned means the domain is not resolving at all. The wrong address means the records were changed: by you, by a CDN, or by a registrar applying its own defaults after a transfer. The DNS troubleshooting guide sets out reading the output.
If it is a 500 or a blank page
The error log has the answer. This is the step that separates a five-minute fix from an afternoon of guessing, and it is the step people skip.
In cPanel, the error log shows the most recent entries with a file and a line number. Understanding cPanel error logs explains finding it.
Then ask what changed. Almost every sudden 500 follows something: a plugin updated, a theme edited, a PHP version changed, an .htaccess rule added.
If you changed something, undo that first. It is faster than diagnosing, and it tells you whether you were right.
Check the disk before anything else on the server
A full account produces a dozen unrelated-looking faults at once: uploads fail, sessions break, the database cannot write, mail is rejected. None of the errors mention disk.
So several things breaking simultaneously is very often just a full account, and the check takes ten seconds. Monitoring your hosting resources goes into where to look.
If it is slow rather than down
A site that hangs and then loads is usually queuing rather than failing.
The tell is timing: fast at night, slow in the afternoon. A code problem is slow consistently; a queue is slow when there is traffic, because requests are waiting for a process to become free.
That is a resource ceiling, and caching is the fix in place of a bigger plan. Caching layers walks through which one is missing.
If it is WordPress
The standard isolation sequence, in this order.
Rename the plugins directory over FTP or File Manager. That deactivates everything at once. If the site returns, the cause is a plugin, rename it back and disable them one at a time.
If it does not, switch to a default theme by renaming the active theme's directory.
If it still does not, rename .htaccess and load the site. A corrupt rewrite block produces a 500 that looks exactly like a plugin fault. See fixing common WordPress errors.
When to contact support, and what to send
Contact them when the server itself is unreachable, when the error log points at something outside your account, or when you have eliminated the application and are still stuck.
Send four things: the exact error text, the time it started, what changed shortly before, and what you have already tried.
That turns a conversation that takes three exchanges into one that takes one. "The site is down" starts a diagnosis from the beginning; the four items above start it from where you got to.
Afterwards, make the next one shorter
Two things pay for themselves the first time they are needed.
Uptime monitoring from outside, so you learn about an outage before a customer tells you. Point the alert at an address that does not depend on this server.
A backup you have restored. An untested backup is a hope. Restoring one once, deliberately, is what makes it a plan. For doing that, see backing up and restoring.
If other people depend on your site, telling them during an outage is worth arranging in advance. There is more in How to Set Up a Simple Status Page.
Slow is a different problem from down, and two commands decide whether hosting is even involved. How to Tell Whether a Slow Site Is the Server or the Site has the detail.
If you host for other people, the first message should go out before you know the cause. How to Tell Clients About Maintenance and Outages goes into what to send and when.