Cloudways Management & Maintenance Guide

Running a site on Cloudways is mostly hands-off, but the accounts that stay fast and recover quickly from problems are the ones where someone handles a short list of routine jobs: verifying backups, keeping cron tasks running, watching logs when something breaks, and scaling before traffic becomes a problem rather than after. This guide is the maintenance playbook for a Cloudways server. It covers what to check and how often, plus links to step-by-step walkthroughs for each task.

What This Guide Covers

This guide covers management and maintenance for Cloudways on Hoos Hosting. It groups the ongoing operational tasks: backups, cron jobs, logs and monitoring, alerts, domain and DNS changes, scaling, and running more than one site on a server. For pricing, what the platform includes, and how it compares to traditional hosting, start with the Cloudways hosting guide. If you have not provisioned a server yet, the Cloudways setup and migration guide comes first; this guide assumes your site is already live.

Your Cloudways Maintenance Routine

Most "maintenance" advice is a pile of one-off tutorials with no sense of cadence. Here is a realistic schedule for a single production site. Adjust the frequency up for high-traffic stores and down for low-change brochure sites.

Weekly Tasks

• Confirm the latest automated backup actually exists and is recent.
• Skim application logs for repeating errors.
• Check that scheduled cron tasks ran on time.

Monthly Tasks

• Run an on-demand backup before any plugin or theme bulk update.
• Review server CPU and RAM trends in the Monitoring tab.
• Test-restore one backup to a staging application so you know the restore path works before you need it.

Quarterly Tasks

• Review whether your server size still fits traffic and scale up or down accordingly.
• Rotate SSH/SFTP credentials for any contractor or ex-team-member access.
• When you need to navigate to your files via SSH or run WP-CLI commands, you will need your Cloudways application folder name.
• Reconfirm DNS records and SSL auto-renewal status (Cloudways renews Let’s Encrypt automatically, but confirm it succeeded under SSL in the Application panel).

As-Needed Tasks

• After a rebrand, change the application domain.
• After a permissions error, reset file and folder permissions.
• Before a traffic spike (sale, launch), scale ahead of time rather than reacting during it.

Backups: On-Demand, Scheduled, and Off-Site

Cloudways runs two backup layers, and confusing them is the most common backup mistake. Application backups capture a single app (files plus database) and are what you restore when one site breaks. Server backups capture the whole server and are the safety net when something goes wrong at the infrastructure level. Set up both. Walk through the steps in how to back up an application on Cloudways and how to back up your server on Cloudways.

Three Rules for Backups That Actually Work

Three rules turn backups from a checkbox into real protection. First, take an on-demand backup immediately before any risky change (plugin updates, theme swaps, PHP version bumps), because the scheduled backup might be hours away. Second, set a retention period long enough to catch slow-burn problems; a corrupted database you notice a week later is useless if backups only go back three days. Third, test a restore at least once a quarter to a staging application. A backup you have never restored is a guess, not a guarantee.

Off-Site Backup Options

Cloudways stores backups on the same infrastructure as your server. For an extra layer of protection, connect an external storage destination: Amazon S3, Google Cloud Storage, or DigitalOcean Spaces. Cloudways supports this natively under Server > Backups > Off-Site Backups. The cost of a few gigabytes on S3 is negligible compared to the value of a clean restore copy that survives a cloud-provider incident.

Cron Jobs and the WP-Cron Trap

Cron jobs run scheduled tasks: publishing posts, sending email digests, clearing caches, pulling reports. On Cloudways you set these up from the dashboard, covered step by step in how to run cron jobs on Cloudways. The catch most WordPress owners hit is WP-Cron. By default WordPress fires its scheduled tasks only when someone visits the site, so a low-traffic site can miss scheduled posts and a high-traffic site can fire WP-Cron too often and waste CPU.

Replacing WP-Cron with a Real Server Cron

The fix is to disable the default WP-Cron behaviour and run it on a fixed schedule with a real server cron, or use the Cloudways Cron Optimizer, which runs WP-Cron reliably regardless of traffic. Set the interval to match your needs (every 5 to 15 minutes is typical) so scheduled posts and emails fire on time without hammering the server.

To disable WP-Cron, add define('DISABLE_WP_CRON', true); to your wp-config.php, then create a server cron in the Cloudways dashboard that calls wp cron event run --due-now via WP-CLI on your desired schedule. This approach gives you predictable firing times and a clear log of when the job ran.

WordPress Core, Plugin, and PHP Updates

Cloudways does not auto-apply WordPress core or plugin updates the way fully managed hosts like Kinsta do. That is by design: a bulk update that breaks a WooCommerce store with heavily customised plugins causes more downtime than an unpatched vulnerability. The responsibility stays with you.

Safe Update Practices

Three practices reduce update risk without creating extra work. First, take an on-demand application backup immediately before any bulk update session. The one-click backup takes under a minute and gives you a same-day restore point if something breaks, rather than rolling back to the previous night’s scheduled backup. Second, enable staging and apply updates there first. Clone your live site to a staging application, run the updates, verify nothing is broken, then update production. Third, check plugin changelogs before updating a plugin you have customised or that sits in the critical path (WooCommerce, Elementor, membership plugins).

PHP Version Changes on Cloudways

For PHP version changes, Cloudways lets you switch versions per application under Application > PHP FPM Settings. PHP 8.1 or 8.2 is the recommended target for WordPress in 2025. Always test in staging first: clone the application, switch PHP on the staging copy, and check the error log in Application > Logs > Error Log for deprecation notices. PHP 8.x catches outdated function calls that worked silently on PHP 7.x, and some popular plugins still throw errors before their authors patch them. Once staging shows a clean error log for 24 to 48 hours, switch production.

Staging Site Workflow on Cloudways

Cloudways makes it easy to clone any application into a staging environment. Understanding when to use staging versus testing on live, and how to push changes back to production cleanly, prevents the most common WordPress update disasters.

When to Use Staging vs. Testing on Live

Use staging for any change that touches the database schema, the theme's core files, PHP version, or a payment gateway plugin. Use live testing only for low-risk tweaks (editing a page draft, changing a widget) where a quick restore takes less time than cloning the app. The rule of thumb: if a bad change could take the site down for more than five minutes, do it in staging first.

Common situations where staging is worth the extra step: PHP version bumps, WooCommerce major version updates, switching page builders, importing large product catalogues, and testing new membership or subscription plugins.

How to Create a Staging Application on Cloudways

In the Cloudways dashboard, open your application and click the "Clone" option. Give the cloned app a clear name (e.g., "mysite-staging") and deploy it to the same server. The clone copies all files and the database. Once it is up, set a staging domain (Cloudways provides a temporary URL), update the WordPress site URL in the staging database, and you have an isolated copy to work in.

Staging apps count toward your server's resources. If your server is already near its CPU or RAM ceiling, clone to a smaller temporary server instead, then terminate it after the test is done.

Pushing Staging Changes to Production

Cloudways does not have a one-click "push staging to production" button like some managed WordPress hosts. The practical workflow is:

• For file changes only (theme edits, plugin code): use SFTP or SSH to transfer the changed files from the staging app to the production app. Compare file timestamps to confirm the right version lands.
• For database changes: export the staging database, search-and-replace the staging domain with the production domain (WP Migrate DB or a search-replace SQL script), then import into production. Always back up production's database first.
• For complete site replacements (after a full rebuild in staging): put production into maintenance mode, push files and database, verify the site loads correctly, then disable maintenance mode.

Staging Gotchas to Watch For

A few issues consistently catch people off guard with Cloudways staging. Payment gateways (Stripe, PayPal, WooCommerce Payments) on a staging clone are still pointed at your live API keys unless you change them. Always switch payment plugins to sandbox/test mode on staging to avoid processing real transactions during a test checkout. Email plugins (WooCommerce order emails, newsletter tools) are similarly live by default; install a mail-catching plugin like WP Mail SMTP set to disabled, or a local mail interceptor, before running any workflow that sends emails.

WordPress nonces and authentication cookies are domain-specific. After cloning, log out and log back in on the staging URL before testing anything that requires authentication. If the staging domain uses HTTP while production uses HTTPS, mixed-content warnings will appear; set SSL on the staging app too, or account for that difference in your test results.

Database Maintenance on Cloudways

WordPress databases accumulate bloat over time: post revisions, expired transients, spam comment records, orphaned metadata from deleted plugins, and WooCommerce order data that never gets trimmed. Left unchecked, a bloated database slows queries and makes exports and backups larger than they need to be.

Checking Database Size in the Cloudways Dashboard

The quickest way to see database size is under Application > Access Details > Database. The dashboard shows the current database name and connection details. For the actual size, connect via phpMyAdmin (available under Application > Access Details > Launch phpMyAdmin) and look at the information_schema. Select your database name in the left panel; phpMyAdmin shows total size next to the database name at the top. A WordPress site with no WooCommerce under a year old should typically be under 50 MB. WooCommerce stores accumulate faster; 200 to 500 MB is common after two to three years of active orders.

Running WP-Optimize From Staging

WP-Optimize is the most widely used WordPress database cleanup plugin. Install it on your staging clone rather than production for the first run. This lets you see exactly what it proposes to remove (post revisions, trash, transients) without touching live data. Review the counts before confirming: 10,000 post revisions being deleted is normal for an old site; 50,000 is a sign someone set WordPress to keep unlimited revisions and you may want to cap it going forward (add define('WP_POST_REVISIONS', 10); to wp-config.php). Once the staging run looks clean, run the same cleanup on production during a low-traffic window and take an on-demand backup beforehand.

MySQL Table Repair via phpMyAdmin

Table corruption is rare but it does happen, usually after a server crash or an abrupt PHP-FPM restart during a write operation. Symptoms include WordPress showing a "Error establishing a database connection" message intermittently, or specific admin screens failing to load while others work. In phpMyAdmin, select all tables for your WordPress database, then choose "Repair table" from the dropdown at the bottom. Most corruption from an interrupted write is recoverable this way. If repair fails, restore from your most recent clean backup; a corrupted InnoDB table that phpMyAdmin cannot repair requires command-line MySQL access, which is available via SSH on Cloudways.

What Table Bloat Looks Like and What Causes It

In phpMyAdmin, look at the "Overhead" column in the table list. Any table showing overhead has fragmented space from deleted rows that MySQL has not reclaimed. The wp_options table is almost always the biggest offender on WordPress sites: plugins store transients, widget settings, and activation data here and rarely clean up after themselves. The wp_postmeta table bloats when plugins that attach metadata to posts are deactivated without running their uninstall routines. The wp_woocommerce_sessions table fills up with abandoned cart sessions if WooCommerce's session cleanup cron is not running. Running "Optimize table" in phpMyAdmin reclaims overhead space without removing any data. Schedule this quarterly, or monthly for high-traffic WooCommerce stores.

Monitoring and Application Logs

When a site is slow or throwing errors, logs and monitoring tell you why before you start guessing. Application logs (access and error) show failed requests, PHP errors, and the plugin or file responsible; the walkthrough is in how to view application logs on Cloudways.

Using the Monitoring Tab Effectively

The Monitoring tab adds the bigger picture. CPU and RAM graphs cover 24 hours, 7 days, or 30 days, so you can see whether high resource usage is a sustained trend or a brief spike. Disk usage trends show when you are approaching capacity (Cloudways does not auto-expand disk; you need to scale the server or clean up old backups). The Running Crons view lists each currently executing cron with its CPU and memory cost, which is how you catch a runaway scheduled task that looks like general server slowness. Check Monitoring weekly for active sites and monthly for low-change ones, so you spot a slow climb in resource use before it becomes downtime.

Three Log Patterns Worth Knowing

A spike in access-log 500 errors usually means a plugin or theme update introduced a PHP fatal error. A flood of the same PHP notice repeating every few seconds often means a cron job has a stuck loop. A gap in the access log during business hours usually means the application crashed and PHP-FPM stopped responding. The error log file path and the exact filter steps are in the application logs walkthrough.

Setting Up Server Notifications and Alerts

Cloudways can send alerts to email or Slack when things go wrong. Without alerts configured, you rely on visitors reporting problems or stumbling on them yourself. Most site owners set up at least two alert types:

• Server resource alerts. Cloudways can notify you when CPU or RAM usage crosses a threshold (80% is a common starting point). Set these under Server > Monitoring > Alerts. Getting an alert at 80% CPU gives you time to investigate before the server hits 100% and requests start timing out.
• Application downtime alerts. The Cloudways uptime monitor pings your application URL at regular intervals and sends an alert if it does not respond. Enable it under Application > Monitoring. Set the alert recipient to the email or Slack channel that someone actually reads urgently.
• SSL certificate expiry alerts. Cloudways auto-renews Let’s Encrypt, but renewal can fail if the domain DNS changes, the certificate rate limit is hit, or Cloudflare Full (Strict) mode blocks the ACME challenge. Set a calendar reminder to manually verify SSL renewal every 60 days, or check the SSL tab monthly during your maintenance review.

Connecting Slack Notifications

For Slack integration, Cloudways supports webhook-based notifications. Add the Slack webhook URL in Team > Notifications inside MyCloudways. Once connected, resource alerts and downtime pings arrive in whichever Slack channel you route them to, which is faster to act on than email during a production incident.

Domain and DNS Changes

Two routine jobs sit here. Changing an application's domain (after a rebrand or moving from a staging URL to the real one) is covered in how to change a domain name on Cloudways; do this in the dashboard rather than editing the database so the change propagates cleanly. For DNS records, Cloudways offers the DNS Made Easy add-on so you can manage records from inside the platform, explained in how to use DNS Made Easy on Cloudways. If you prefer a faster external DNS layer, point your domain at Cloudflare instead and manage records there.

After updating DNS for an application, install or verify your SSL certificate. Our step-by-step guide covers how to install SSL on Cloudways using either the free Let’s Encrypt option or a custom certificate.

What to Do When Your Site Goes Down

Even well-maintained servers have incidents. When a Cloudways site stops responding, a repeatable diagnostic sequence gets it back up faster than guessing.

Diagnostic Sequence for a Down Site

1. Check the Cloudways status page first. Infrastructure-level outages at DigitalOcean, Vultr, or AWS affect all sites on that provider. If the provider is the cause, the fix is outside your control; monitor the status page and wait.
2. Check the error log. Go to Application > Logs > Error Log. The most recent entries tell you the exact PHP error, the file, and the line number. A plugin update that introduced a fatal error is the most common cause; the log points to the specific file.
3. Check server resource usage. If the error log is clean, go to Monitoring. A server at 100% CPU or RAM starts rejecting connections. The fix is usually scaling up (temporary) and then tracking down the runaway process (permanent). The Running Crons view shows runaway tasks.
4. Reset file permissions. A permissions error after a plugin install or FTP upload causes 403 and 500 errors. The one-click reset is in Application > Settings > Reset Permissions. This is safe to run on a live site.
5. Restore from backup. If the error is from a specific change (plugin update, content import, code push), restore the application backup from before that change. Cloudways restores take a few minutes and do not require contacting support.
6. Contact support. If none of the above resolves it, open a live chat ticket with the error log contents and the timeline of what changed before the outage. Cloudways support can connect directly to the server for issues outside the application layer.

Scaling vs Migrating

Cloudways lets you scale a server's RAM and CPU in a few clicks, which is the right move when a single site outgrows its current size. The step-by-step process and tier guidance are in our guide on how to scale a Cloudways server. But scaling is not always the answer. If you need a fundamentally different setup (a different cloud provider, a different region, or dedicated resources), moving may beat scaling. Two questions worth answering up front: does Cloudways even fit your needs versus a plain VPS, covered in does Cloudways have a VPS?, and how the managed-cloud model differs from traditional hosting, covered in Cloudways vs regular hosting. One honest limitation to plan around: on the standard managed plans you do not get full root access, so workflows that require it need a different host.

Running Multiple Sites and Choosing Infrastructure

A single Cloudways server can host several applications, which is the cheapest way to run a small portfolio of sites. The tradeoffs (shared resources, noisy-neighbour risk between your own apps) are covered in running multiple websites on a Cloudways server. Two decisions shape performance more than anything else on this platform: which underlying cloud provider you pick, explained in which hosting supplier to choose on Cloudways, and which data-centre region you deploy to, covered in how to choose the best Cloudways server location. Pick the region closest to most of your visitors; latency from a distant region is the single easiest performance mistake to avoid.

Where to Go Next

Maintenance overlaps with two neighbouring areas. For caching, CDN, and WordPress speed tuning, see the Cloudways performance and speed guide. If you are deciding between the free Breeze plugin and a premium option, our guide on WP Rocket on Cloudways covers when it is worth the cost and how it compares to Rocket.net as a hosting alternative. For SSL, HTTPS redirects, and file permission hardening, see the Cloudways security and SSL guide. To launch Cloudways or move an existing site onto it, the setup and migration guide covers provisioning and migration. Ready to start a server? Try Cloudways and follow the setup guide.

Frequently Asked Questions

How often should I back up my Cloudways site?

Set automated backups to run daily for any active site and retain at least 14 days of history. Take an additional on-demand backup before any risky change (plugin bulk updates, PHP version switch, theme replacement). For WooCommerce stores processing daily orders, consider twice-daily automated backups so you never lose more than 12 hours of order data in a worst-case scenario. Test a restore to a staging application at least once per quarter to confirm the backup is actually usable.

Does Cloudways handle WordPress updates automatically?

No. Cloudways does not auto-apply WordPress core, plugin, or theme updates. The platform manages server-level software (PHP, MySQL, Nginx, Varnish), but WordPress-layer updates are your responsibility. This is intentional: a bulk plugin update that breaks a customised WooCommerce setup can cause more downtime than a delayed patch. The recommended workflow is to clone the application to staging, apply all updates there, verify nothing breaks over 24 to 48 hours, then apply the same updates to production.

How do I reduce database bloat on a Cloudways WordPress site?

Start by identifying the largest tables via phpMyAdmin under Application > Access Details. The usual culprits are wp_options (plugin transients and orphaned settings), wp_postmeta (metadata from deleted plugins), and wp_woocommerce_sessions (abandoned cart sessions). Install WP-Optimize on a staging clone first, review what it proposes to delete, then run the same cleanup on production during off-peak hours. Add a post revision cap to wp-config.php to stop the problem recurring. Run phpMyAdmin's "Optimize table" command quarterly to reclaim fragmented overhead without removing any data.