5 Hosting Mistakes That Can Get Your Site Suspended

You log in one morning and your site is offline. Your hosting provider has suspended your account. No warning. No explanation beyond a generic “Terms of Service violation.” You cannot reach your data. Your email is bouncing. Your customers cannot reach you.

This happens more often than people think. Most suspensions are preventable. Here are the five mistakes that cause the most suspensions, what the warning signs look like, and what to do if it has already happened to you.

Mistake #1: Ignoring Resource Limits

The single most common suspension cause. You signed up for “unlimited” hosting, but every host has limits. They are buried in the Terms of Service. You exceed them. Your site gets suspended.

What the limits actually are:

• CPU usage (often 25-50% sustained for shared hosting)
• RAM usage (often capped at 2-4 GB even on “unlimited” plans)
• Number of concurrent processes
• Number of inodes (files and directories)
• Database size and query load
• Outbound email volume
• Bandwidth (rarely unlimited in practice)

The trap: the marketing page says “unlimited resources.” The TOS says “unlimited subject to acceptable use policy.” The acceptable use policy says “we will suspend accounts that impact server performance.” That last clause covers everything.

Warning signs:

• Site gets slow during traffic spikes
• CPU warnings in cPanel
• Database queries time out
• Email sending suddenly fails
• Host sends a “resource usage warning” email (most people ignore these)

The fix:

• Enable caching (page cache, object cache, OPcache)
• Optimize database queries
• Compress and resize images before uploading
• Move heavy workloads to a VPS
• Set up monitoring so you see resource usage before the host does
• Read your TOS for the actual limits

If your site is genuinely growing, that is a good problem. Upgrade to a VPS or dedicated server before the host forces the issue.

Mistake #2: Mailing the Wrong Way

Email is the second most common suspension cause. People use shared hosting for mass mail and get shut down.

What goes wrong:

• Sending newsletters through PHP mail() instead of SMTP
• Sending more than a few hundred emails per day from a shared host
• Sending to old lists with high bounce rates
• Sending email without proper SPF/DKIM/DMARC records
• Forwarding mail through the hosting server when the forwarding address bounces

Why hosts care: if your email gets the host’s IP blacklisted, every other customer on that IP suffers. Shared hosting providers are aggressive about email volume limits because they have to be.

Warning signs:

• Emails go to spam
• Bounce rates increase
• Host sends an “email abuse” warning
• Outbound mail starts failing

The fix:

• Use a dedicated email service (Mailgun, SendGrid, Postmark, Amazon SES) for any volume over 100 emails/day
• Configure SPF, DKIM, and DMARC properly
• Clean your email lists regularly
• Never use the host’s mail server for marketing email
• If you need transactional email at scale, use a transactional provider

Email is its own infrastructure for a reason. The moment you are sending more than a few hundred emails a day, you need a real email service. Your host is the wrong tool.

Mistake #3: Running Cron Jobs That Misbehave

Cron jobs are scheduled tasks. They run in the background. When they misbehave, they take the whole server down with them.

Common cron mistakes:

• A cron job that runs every minute and never finishes
• A cron job that spawns child processes that accumulate
• A backup script that fills the disk
• A log rotation script that fails and leaves logs growing
• A WP-Cron or similar that duplicates itself under load

Why it gets you suspended: when one cron job consumes all CPU, every other site on the shared server suffers. The host has no choice but to kill the process or suspend the account.

Warning signs:

• Site slows down at specific times (every hour, every day)
• CPU spikes line up with cron schedules
• Multiple cron jobs running simultaneously
• “killed process” errors in logs

The fix:

• Add locks to cron jobs so only one instance runs at a time
• Stagger cron schedules
• Add timeouts and resource limits to cron scripts
• Monitor cron output for errors
• Use systemd timers or supervisord instead of raw cron for long-running tasks
• Test cron jobs on a staging environment first

A bad cron job can take down a server. This is the kind of thing shared hosting providers have zero tolerance for.

Mistake #4: Getting Hacked

The fourth big one. Your site gets compromised. Attackers use it to send spam, host phishing pages, mine crypto, or attack other servers. The host detects the abuse and suspends your account.

How sites get hacked:

• Outdated WordPress/plugins/themes with known vulnerabilities
• Weak passwords reused across services
• Unused admin accounts from old developers
• Vulnerable custom code (SQL injection, file upload bugs)
• Compromised dependencies in package managers
• Stolen credentials from data breaches elsewhere

What happens after a hack:

• Attacker injects phishing pages into your site
• Attacker sends spam using your forms or mail()
• Attacker uses your server as a botnet node
• Host detects outbound abuse from your account
• Host suspends your account with little warning

Warning signs:

• Files you did not upload appear in your directories
• Outbound traffic spikes from your server
• Your site shows up on Google Safe Browsing or PhishTank
• Host sends a malware warning
• Search results for your site show pharma or spam content

The fix (before):

• Keep everything updated – CMS, plugins, themes, dependencies
• Use strong unique passwords with a password manager
• Enable 2FA on your hosting account and admin panels
• Limit admin access to specific IPs where possible
• Use a WAF (Web Application Firewall) like Cloudflare
• Run security scans regularly (Wordfence, Sucuri, or similar)

The fix (after):

• Do not pay the host to “clean” the site. Restore from a known-clean backup.
• Identify the entry point and close it
• Rotate all credentials
• Submit a review request to Google Safe Browsing if listed
• Take the lesson and harden everything before going live again

Hacked sites get suspended fast. The host is protecting other customers. The faster you clean up, the faster you recover.

Mistake #5: Backups You Did Not Test

This one is sneaky. You have backups. You are responsible. The host suspends your account for some other reason. You try to restore from backup. The backup is corrupted, incomplete, or 6 months old.

Why backups fail when you need them:

• Backup script ran but failed silently
• Backup was incomplete due to a timeout
• Backup was stored on the same server (gone when the server is)
• Backup format is incompatible with anything else
• You never tested restoring from backup

The trap: “I have backups” feels safe. Until you actually need them. Then you discover the backup is from March, the database is missing, or the file is unreadable.

The fix:

• Use the 3-2-1 rule: 3 copies, 2 different media types, 1 offsite
• Test restoring from backup at least quarterly
• Verify backup integrity automatically (checksums)
• Store backups in a different provider or at least a different account
• Keep daily backups for the last 30 days
• Keep weekly backups for the last 6 months
• Document the restore process while you are calm, not during a crisis

If you cannot restore from backup in under an hour, your backups are not really backups. They are files that happen to exist.

Other Things That Get Sites Suspended

A few less common but real causes.

DMCA complaints. Hosting providers must respond to copyright complaints. Repeated complaints get you suspended.

Phishing reports. If your site is used for phishing (often after a hack), the host and Google will move fast.

Illegal content. Things that vary by jurisdiction but include certain types of adult content, hate speech, drugs, weapons sales.

Spam comments or forms. Not just email – if your contact forms are used to spam others, the host may act.

Phishing of your own users. A hacked site that phishes your users will get reported and suspended.

Resource abuse that affects other customers. Even if not on the “limit” list, anything that hurts the shared server gets attention.

Most of these are downstream of the five main mistakes. Fix the basics and you avoid most suspensions.

What to Do If You Have Been Suspended

If this already happened to you.

Step 1: Do not panic. Do not pay ransom. Some hosts will hold your data hostage. Read your TOS for the suspension appeals process.

Step 2: Identify the cause. Ask support specifically: what triggered the suspension? Resource abuse, spam, malware, TOS violation? Get it in writing.

Step 3: Fix the underlying issue. If it is malware, clean the site or restore from backup. If it is resource abuse, optimize or upgrade. If it is spam, secure your email.

Step 4: Appeal in writing. Be specific, professional, and solution-focused. Show what you fixed. Offer to commit to monitoring or limits.

Step 5: Have backups ready. If the suspension is permanent and you cannot recover the account, you need your own backups to migrate.

Step 6: Move providers if needed. Some suspensions are legitimate. Some are mistakes or unfair. If the latter, switch providers.

The fastest path back online is usually to spin up a new account on a different host, restore your own backup, fix the root cause, and move on. Do not waste weeks fighting an unwilling provider.

How to Prevent This Entirely

A few habits that prevent 95 percent of suspensions.

Read your TOS. Know the actual limits on your plan. The marketing page is fiction; the TOS is reality.

Set up monitoring. Use a free uptime monitor and resource monitor. Know your baseline CPU and memory usage.

Use a real email service. For any volume above a few hundred emails per day, Mailgun or SendGrid. Never your host.

Update everything weekly. WordPress, plugins, themes, server packages. Automate where you can.

Test your backups. At least quarterly. Document the restore process.

Have a plan to migrate. Know how you would move to another host if needed. Keep DNS under your control, not delegated to the host.

Communicate early. If you are about to exceed limits, talk to support before they come to you. Most hosts will work with you on a plan.

These habits turn suspensions from a crisis into a non-event. The hosts that take uptime seriously support customers who take their own infrastructure seriously.

Conclusion

Most suspensions are preventable. The five mistakes above cause the vast majority. None of them are exotic. All are well-documented and well-understood.

The fix is not complicated: respect resource limits, use proper email services, monitor your cron jobs, keep your site secure, and test your backups. Do these things and you will probably never experience a suspension.

If you do get suspended, do not panic. Fix the root cause, restore from your own backup, and move providers if needed. The goal is not to win the fight with your host. The goal is to get your site back online.

Treat your hosting relationship as a partnership. Stay under the limits. Communicate when something is wrong. Keep your own backups. The host stays out of your way. You stay online. Everyone wins.