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 is the management and maintenance hub 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 parent 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: confirm the latest automated backup actually exists and is recent. Skim application logs for repeating errors. Check that scheduled cron tasks ran.
- Monthly: run an on-demand backup before any plugin or theme bulk update. Review server CPU and RAM trends in Monitoring. Test-restore one backup to a staging app so you know the restore path works before you need it.
- Quarterly: review whether your server size still fits traffic (scale up or down). 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: 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.
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 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.
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.
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.
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.
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).
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-48 hours, switch production.
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.
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; 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.
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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. 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.
