Your host suspended the account. The email gives you a sentence or two, no evidence, and a ticket you have to answer — and the site is offline right now. In almost every case the trigger is one of four things: malware in your files, a resource limit you crossed, an abuse complaint, or a billing failure. The first hour is not about fixing the site; it is about working out which of those four it is, so you can reply with facts instead of apologies.

The short version

• Get the actual reason in writing. “Terms of service violation” is not a reason, and you cannot fix what you cannot name.
• Take a full backup before you change anything — files and database. Some hosts restore from their own copy, some do not.
• Look for the cause in your own logs while the account is still suspended. File access usually survives even when the site does not.
• Reply with what you found, what you changed, and when it is safe to review. Then ask for the exact condition that lifts the suspension.
• Keep a migration path ready: a short DNS TTL and an off-site backup are what turn a suspension into an afternoon instead of a week.

First, work out which suspension you are in

The wording in the email matters more than the tone. Hosts send roughly the same four messages, and each one needs a different answer. If you reply with a general “sorry, I have fixed it” you will usually get a general “we are still reviewing it” back.

If the panel still lets you log in, do it now and read the resource graph before anything else. A suspension that arrives at 02:00 with a CPU line in the email is almost always traffic or a cron job, not a person attacking you.

Collect the evidence before you reply

Most suspensions still leave you with file access through the panel’s file manager or over FTP. That is enough to find the cause. The access log is the fastest place to look, and on cPanel it usually sits in ~/logs or /home/<user>/access-logs; on Plesk it is under /var/www/vhosts/<domain>/logs. If you have never opened it, the mechanics are the same ones I covered in the article on HTTP 500 and which log tells you why.

# which IPs are hitting you hardest
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

# which URLs they are hitting (wp-login.php is the usual suspect)
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -10

# files changed in the last 7 days
find wp-content -type f -mtime -7 | head -40

Three patterns cover most cases. One IP with thousands of requests is a bot or a scraper and you can block it at the firewall. Thousands of requests spread over hundreds of IPs hitting wp-login.php or xmlrpc.php is a distributed brute-force attempt, and the host may suspend you just to stop the load. Heavy requests to a single PHP file that is not part of WordPress is usually malware. If the files look wrong rather than the traffic, run the checks in my five-minute infection check and screenshot the results — hosts accept evidence.

Stop the bleeding without making it worse

The instinct is to reinstall everything at once. Do not. You cannot tell the host what you fixed if you have replaced half the site, and you cannot compare anything against a clean state. Work in this order instead:

• Rename, don’t delete. Move the suspected plugin folder to wp-content/plugins-disabled/ so the site stops loading it but you can put it back. Deleting means you cannot inspect it later.
• Kill the cron. A runaway scheduled task keeps firing even while the site is suspended, which is how a “temporary” suspension turns into a repeat one. Disable WP-Cron in wp-config.php until you are restored.
• Close the front door. Block the offending IP range in .htaccess or the panel firewall, and disable XML-RPC if you do not use it.
• Leave the database alone. Dropping tables or removing users during a review removes the evidence the host may ask for.

Reply like an engineer, not a defendant

A reply that gets an account restored quickly reads like a short incident report. Six lines, no paragraphs of apology:

1. What happened, with the timestamp and the log evidence you found.
2. What caused it, in one sentence — a plugin, a botnet, an outdated theme file.
3. What you changed, listing the exact files or settings you touched.
4. How you verified it, such as the log now showing no requests from that range.
5. What stops it recurring, such as a firewall rule and a patched plugin.
6. The direct question: what is the specific condition for lifting the suspension, and can they confirm when they will review it.

Ask for the threshold too. If the suspension was for CPU or entry processes, you need to know the number you exceeded or you will cross it again next month. If the host cannot tell you, that is itself useful information about whether to stay.

If they will not restore it, move — in the right order

Some hosts suspend first and investigate later, and a few never give you a clear answer. You can still move, but the order matters. Download a full backup of files and database from the panel before the account is terminated; after termination it may be gone. Lower the DNS TTL to 300 seconds and wait for the old value to expire. Restore on the new host, test it by pointing your own machine at the new IP with the hosts file, and only then switch the nameservers. That is the same sequence as moving a site without downtime, minus the luxury of planning ahead.

The first hour, in order

1. Read the email and classify the suspension: malware, resources, abuse, or billing.
2. Log into the panel if you still can; download a full backup to your own machine.
3. Pull the access log and find the top IPs and top URLs.
4. List files modified in the last seven days and check for unknown admin users.
5. Rename the offending plugin or block the offending range; disable WP-Cron.
6. Reply with the six-line incident report and one direct question.
7. Lower DNS TTL now, even if you expect to stay.
8. Write down what you changed and when — you will need it in the next ticket.

None of this needs a hosting company’s permission, and most of it takes less than an hour. The one thing worth doing before you ever need it: keep a recent off-site backup and a TTL short enough that a move is measured in minutes. If you have neither, fix that today — because the next suspension email will not arrive at a convenient time. Open the ticket and write three lines: what you found, what you changed, and when it is safe to review. That single reply does more for you than a week of apologising.