Summarize this blog post with: ChatGPT | Perplexity | Claude | Grok

Your Cloudways website may already be displaying an error, loading slowly, or refusing to open, and you have probably tried refreshing the page or clearing a cache. The missing step is identifying whether DNS, SSL, WordPress, caching, the database, server resources, or the Cloudways platform is actually failing. In this guide, you will learn how to isolate the root cause, apply the lowest-risk fix, and prevent the problem from returning.

Last reviewed: August 3, 2026.

Key Takeaways

• Cloudways troubleshooting isolates website failures across local devices, DNS, SSL, WordPress, caching, databases, server services, and hosting infrastructure.
• Initial diagnosis should confirm the scope of the outage, check Cloudways Status, document recent changes, and preserve relevant logs before applying fixes.
• Cloudways Monitoring can reveal CPU pressure, RAM consumption, disk constraints, database connections, bandwidth patterns, and recurring cron activity.
• HTTP 500-series errors usually require log analysis, application-conflict checks, backend-service verification, and resource investigation rather than repeated page refreshing.
• DNS and SSL diagnosis should compare the custom domain, Cloudways application URL, DNS records, certificate hostname, HTTPS behavior, and Cloudflare settings.
• Backups and staging environments reduce troubleshooting risk by providing a controlled testing environment and a viable rollback path.
• Support escalation should include incident timestamps, affected URLs, application and server identifiers, log excerpts, resource graphs, recent changes, and actions already attempted.

What Is Cloudways Troubleshooting and Which Website Layers Can Fail?

Cloudways troubleshooting is the systematic process of isolating website failures across the DNS, SSL, application, caching, database, server, and hosting-platform layers. The objective is to distinguish the visible symptom from the underlying root cause before changing production settings.

A symptom describes what the user sees. For example, “the checkout is slow” is a symptom.

An error provides a technical signal. For example, “503 Service Unavailable” is an HTTP error.

A root cause explains why the failure occurred. For example, PHP-FPM workers may be saturated by uncached WooCommerce requests.

A corrective action addresses the confirmed cause. For example, optimizing a slow checkout query is a corrective action, while repeatedly restarting PHP-FPM is only temporary recovery.

Readers who need broader platform context should begin with the complete Cloudways hosting guide before using this incident-focused workflow.

Which Cloudways website layers can fail?

A Cloudways-hosted website depends on several connected layers:

Cloudways Flexible and Cloudways Autonomous do not always expose identical navigation paths, restore controls, service-management options, or server responsibilities. Cloudways documentation now separates several workflows by product, so every screenshot and dashboard instruction should identify the applicable environment.

[Insert image: Custom diagram showing local device, DNS, SSL, CDN, WordPress, cache, database, server, Cloudways, and cloud-provider layers | Alt text: “Diagnose Cloudways troubleshooting layers from DNS to server”]

Why Is a Structured Cloudways Troubleshooting Process Important?

A structured Cloudways troubleshooting process reduces downtime by preserving evidence, narrowing the failure domain, and preventing unrelated changes from introducing additional problems. Cloudways root-cause analysis involves confirming the scope of the outage, reviewing recent changes, examining logs, checking resource metrics, and testing one corrective action at a time.

Random troubleshooting creates two risks. First, clearing caches, restoring backups, or restarting services may erase the original evidence. Second, simultaneous changes make it difficult to identify which action restored service.

For example, suppose a WooCommerce checkout starts returning 503 errors immediately after a payment-plugin update. Scaling the server, purging every cache, changing DNS, and restarting PHP-FPM together may restore the checkout temporarily, but that sequence does not prove what failed.

Preserve evidence before changing production

Record the following before making moderate- or high-risk changes:

• Exact error text and HTTP status code
• First observed time and timezone
• Last known working time
• Affected URLs and user journeys
• Whether one or every application is affected
• Recent plugin, theme, PHP, deployment, DNS, or SSL changes
• Screenshots or screen recordings
• Relevant log entries
• CPU, RAM, disk, inode, database, and traffic graphs
• Actions already attempted and their results

“Backups are essential for every website—whether you manage a personal blog, an online store, or a business site.”

— Syed Abuzar Mehdi, Cloudways Help Center author, 2026

The quotation matters because troubleshooting often requires changing code, configuration, or data. A verified restore point turns a risky experiment into a reversible procedure.

Create a Cloudways Backup Before Troubleshooting

Before changing production files, plugins, PHP settings, or database content, create a recoverable backup. This official Cloudways tutorial demonstrates scheduled backups, on-demand backups, application-level backups, server-level backups, and local backup downloads.

Video: “How to Backup Servers and Applications | Cloudways 101” by Cloudways.

Classify each troubleshooting action by risk

Do not do these actions first

Avoid the following opening moves:

• Restoring an unverified backup point
• Changing DNS during a PHP or WordPress error
• Scaling before examining the source of the resource spike
• Clearing every cache before recording the original response
• Editing production files without a backup
• Disabling all plugins during peak WooCommerce sales
• Repeatedly restarting services without reading the logs
• Turning on visible PHP error output for public visitors

A service restart can restore availability without resolving the root cause. For example, PHP-FPM may restart successfully and fail again because a bot surge, runaway cron job, memory leak, or inefficient database query remains active.

What Should You Check First When a Cloudways Website Stops Working?

The first Cloudways troubleshooting step is to determine who is affected, what changed, and which infrastructure layer still works. A five-minute triage should test the site from another environment, check Cloudways Status, compare the custom domain with the application URL, review logs, and inspect resource graphs.

Pre-troubleshooting evidence checklist

Capture these five facts before touching configuration:

1. Scope: One visitor, one region, one application, or every application?
2. Timing: When did the failure begin?
3. Change: What was deployed, updated, migrated, or reconfigured?
4. Signal: Which error, log entry, or metric changed?
5. Impact: Is the failure affecting browsing, admin access, checkout, APIs, or all traffic?

The five-minute Cloudways troubleshooting checklist

1. Test in an incognito window. This removes many cookie, browser-cache, and extension variables.
2. Test another device and network. Mobile data is useful for separating a local ISP problem from a public outage.
3. Check Cloudways Status. The official status page publishes incidents and maintenance notices and supports incident subscriptions.
4. Compare the custom domain and application URL. If the application URL works but the domain fails, investigate DNS, SSL, or CDN configuration.
5. Test another application on the server. One failing application suggests an application issue; every failing application suggests a server or platform issue.
6. Review recent changes. Check plugin updates, deployments, DNS edits, PHP changes, SSL renewals, cron edits, and scaling events.
7. Open application logs. Cloudways supports log viewing through the platform and through SSH or SFTP.
8. Inspect monitoring graphs. Review CPU, RAM, disk I/O, network traffic, swap, database connections, and application-level metrics.
9. Confirm a usable backup. Create an on-demand backup before high-risk work when the application remains stable enough to do so.
10. Choose one path: Apply a low-risk fix, roll back a known change, restore a verified backup, scale confirmed capacity, or escalate.

The Cloudways server monitoring guide provides a deeper interpretation of resource graphs and recurring performance patterns.

Use the “one application or every application” test

The fastest Cloudways diagnostic discriminator is often this question:

Does one application fail, or does every application on the same server fail?

• One application fails: Focus on WordPress, plugins, themes, application configuration, database tables, application files, and application-specific traffic.
• Every application fails: Focus on server services, disk capacity, inodes, database availability, networking, provider incidents, and Cloudways infrastructure.
• Multiple independent servers fail: Check Cloudways Status, the underlying provider, DNS, CDN, and account-wide configuration.

Symptom-to-evidence-to-action matrix

How Can You Tell Whether Cloudways Is Down or Only Your Website Is Affected?

You can determine whether Cloudways is down by testing the incident scope across devices, domains, applications, servers, and the official status page. A platform-wide incident usually affects multiple independent resources, while a domain, SSL, WordPress, or server problem produces a narrower and more reproducible failure pattern.

Cloudways diagnostic decision tree

1. Does the site work on another device or network?
   • Yes: investigate the original browser, local DNS, firewall, VPN, or network.
   • No: continue.
2. Does the Cloudways application URL work?
   • Yes: investigate DNS, the custom domain, SSL, redirects, or CDN.
   • No: continue.
3. Does another application on the same server work?
   • Yes: investigate the failing application.
   • No: continue.
4. Does another Cloudways server work?
   • Yes: investigate the affected server or cloud-provider region.
   • No: continue.
5. Does Cloudways Status show an incident?
   • Yes: preserve evidence, subscribe to updates, and avoid unnecessary production changes.
   • No: contact Cloudways Support with the collected diagnostics.

[Insert image: Flowchart that separates local, DNS, SSL, application, server, and Cloudways-platform failures | Alt text: “Identify whether Cloudways is down or one website is affected”]

Commands that help isolate the failing layer

Check the HTTP response: curl -I https://example.com

Follow the complete redirect chain:curl -I -L https://example.com

Check the IPv4 address returned by DNS:

dig +short example.com A

Check the www hostname:

dig +short www.example.com

Use a Windows-compatible DNS query:

nslookup example.com

Inspect the network route on Linux or macOS:

traceroute example.com

Inspect the route on Windows:

tracert example.com

A raw server-IP test is useful for network reachability, but it may produce an SSL hostname mismatch. The Cloudways application URL is usually a more useful comparison when testing HTTPS behavior.

How Do You Troubleshoot Common Cloudways HTTP Errors?

Cloudways HTTP error troubleshooting begins by identifying whether the response represents a client request problem, missing resource, rate limit, application failure, unavailable backend, or upstream timeout. The status code narrows the investigation, but logs, resource graphs, and recent changes are still required to confirm the cause.

The IETF HTTP semantics standard defines 502 as an invalid upstream response, 503 as temporary unavailability, and 504 as an upstream response timeout.

How do you fix a 400 Bad Request error on Cloudways?

A 400 Bad Request means the server rejected a request it considered malformed. Start by clearing cookies for the affected hostname, testing an incognito window, checking oversized or malformed headers, and reviewing proxy or security rules.

If the error affects only one form, API endpoint, or upload, reproduce it while the browser Network panel is open. Compare the request method, headers, payload, and response with a working request.

How do you fix a 401 Unauthorized error on Cloudways?

A 401 Unauthorized response indicates that valid authentication is required. Check Cloudways application password protection, WordPress login cookies, API credentials, authorization headers, and security-plugin rules.

After a migration, distinguish WordPress admin credentials from frontend HTTP authentication. Cloudways documents HTTP authentication and frontend password protection as separate migration controls.

How do you fix a 403 Forbidden error on Cloudways?

A 403 Forbidden response means the server understood the request but refused access. Inspect file ownership, Cloudways application permissions, .htaccess rules on compatible stacks, security plugins, blocked IP addresses, and CDN firewall events.

Cloudways provides a dashboard permission-reset operation for the application webroot. Its documented defaults reset directories to 775 and files to 664, but the correct ownership choice still matters.

Do not apply recursive permission commands copied from an unrelated hosting guide. Use Cloudways’ documented reset function or involve Support when ownership is unclear.

How do you fix a 404 Not Found error on Cloudways?

A 404 Not Found response means the server was reached but could not locate the requested resource. Test whether the homepage works, resave WordPress permalinks, verify the file path, inspect rewrite rules, and confirm that the correct webroot is configured.

Cloudways identifies misconfigured .htaccess, file permissions, missing migration files, plugins, and missing theme assets as potential 404 causes. Cloudways also recommends checking logs and purging relevant caches after correcting the cause.

A 404 on every internal WordPress URL but not the homepage often points to permalink or rewrite handling. A 404 on one image usually points to a missing file, wrong URL, CDN path, or incomplete migration.

How do you fix a 408 Request Timeout error on Cloudways?

A 408 Request Timeout means the server did not receive a complete request within the expected period. Test another network, inspect upload behavior, check request size, and determine whether a proxy or security layer interrupted the request.

If only long form submissions or uploads fail, compare the failure with the 413 and 504 sections. A 408 may reflect client-to-server timing, while a 504 reflects a gateway waiting too long for an upstream service.

How do you fix a 413 Request Entity Too Large error on Cloudways?

A 413 Request Entity Too Large error occurs when an upload or request body exceeds the permitted web-server or PHP limits. Cloudways exposes an Upload Size setting under server settings, while advanced cases require alignment between Nginx and PHP directives such as post_max_size and upload_max_filesize.

Use this sequence:

1. Confirm the actual upload size.
2. Increase the Cloudways Upload Size above the file size.
3. Confirm post_max_size is not lower than upload_max_filesize.
4. Check plugin-specific upload limits.
5. Restart PHP-FPM only when configuration changes require it.
6. Retest the exact upload.

Avoid increasing limits indefinitely. A very large upload may be safer through SFTP or an application-specific import process.

How do you fix a 429 Too Many Requests error on Cloudways?

A 429 Too Many Requests response indicates that the client has exceeded a rate limit. RFC 6585 defines the status for request-rate limiting and allows a server to provide a Retry-After response header.

Check:

• Cloudflare rate-limiting or security events
• WordPress security plugins
• Repeated API calls
• Aggressive uptime monitors
• Broken scripts retrying without delay
• Bot traffic
• Login brute-force activity
• WooCommerce webhooks or integrations

The correct fix is usually to reduce abusive or duplicate requests, add backoff behavior, or adjust a confirmed rate-limit rule. Do not disable security controls before identifying the requester.

How do you fix a 500 Internal Server Error on Cloudways?

A Cloudways 500 Internal Server Error indicates that the application encountered an unexpected condition that prevented it from completing the request. Check PHP and application logs first, then investigate recent code changes, plugins, themes, rewrite rules, memory exhaustion, and permissions.

Cloudways recommends taking a backup before code or database changes, examining PHP logs, reverting recent changes, auditing plugins, checking .htaccess, reviewing memory, and resetting permissions where appropriate.

Use this order:

1. Match the 500 timestamp with the PHP or Apache error log.
2. Roll back the most recent deployment or plugin change.
3. Test the failing path in staging.
4. Deactivate only the suspected plugin or theme.
5. Regenerate rewrite rules if the stack supports .htaccess.
6. Check memory exhaustion and missing PHP dependencies.
7. Reset Cloudways permissions when logs indicate an access problem.
8. Escalate repeated or unexplained failures.

How do you fix a 502 Bad Gateway error on Cloudways?

A Cloudways 502 Bad Gateway error occurs when the proxy layer cannot receive a valid response from an upstream service such as PHP-FPM or another backend component. Likely causes include backend-service failure, request timeout, server overload, database pressure, plugin conflicts, or application code that terminates unexpectedly.

Use this sequence:

1. Check whether one application or every application fails.
2. Review CPU, RAM, database connections, and traffic.
3. Match the 502 timestamp with PHP and web-server logs.
4. Check for a recent plugin, theme, PHP, or deployment change.
5. Verify the relevant services in the Cloudways dashboard.
6. Restart only services that appear failed or unresponsive.
7. Purge Varnish when an old 502 response remains cached.
8. Continue root-cause analysis after availability returns.

“If this is the case, the solution is simple: restart Apache, Nginx, PHP-FPM, and purge Varnish from the Manage Services section.”

— Usama Zafar, Cloudways Help Center author, 2024

This Cloudways instruction applies when those services exist in the selected stack and a service failure is the confirmed cause. Cloudways Flexible, Lightning Stack, Hybrid Stack, and Autonomous environments may expose different services, so do not restart components that are absent from your environment.

How do you fix a 503 Service Unavailable error on Cloudways?

A 503 Service Unavailable response means the server is temporarily unable to process the request, commonly because of overload, maintenance, worker pressure, or application-level capacity constraints. The IETF standard describes 503 as temporary inability caused by overload or maintenance.

For WordPress and WooCommerce, inspect:

• PHP-FPM worker pressure
• Database connection saturation
• Action Scheduler backlogs
• Uncached checkout and account requests
• Maintenance mode
• Bot or traffic spikes
• Long-running imports
• Backup or cron activity
• External payment or API delays

If only checkout fails, do not purge customer sessions or disable every plugin during active trading. Inspect the payment gateway, WooCommerce logs, scheduled actions, and dynamic-request load first.

How do you fix a 504 Gateway Timeout error on Cloudways?

A 504 Gateway Timeout response means a proxy did not receive a timely response from an upstream server. The slow component may be PHP, MySQL or MariaDB, an external API, a payment gateway, a search service, or another backend dependency.

Check the slowest request in browser developer tools, PHP logs, slow database queries, external HTTP calls, cron processes, and application monitoring. Increasing timeout values may hide the symptom while leaving the slow process unchanged.

Optimize the slow query or external dependency before raising execution limits. Increase a timeout only when the operation is legitimate, controlled, and expected to require additional time.

How do you fix too many redirects on Cloudways?

A too many redirects error occurs when two or more rules continually send the browser between different URLs or protocols. Common conflicts involve WordPress Address, Site Address, Cloudways HTTPS redirection, Cloudflare SSL mode, www canonicalization, plugins, HSTS, and origin redirects.

Follow the redirect chain: curl -I -L https://example.com

Then compare:

• http versus https
• Root domain versus www
• WordPress Address versus Site Address
• Cloudflare encryption mode
• Cloudflare Always Use HTTPS
• Cloudways HTTPS redirection
• Plugin and .htaccess redirects
• Application or framework routing

Cloudflare documents that Flexible mode can loop when the origin redirects HTTP to HTTPS, while Full or Full (strict) can loop when the origin redirects HTTPS back to HTTP.

How do you fix ERR_CONNECTION_REFUSED on Cloudways?

ERR_CONNECTION_REFUSED means the connection was actively rejected before a valid HTTP response was returned. Test the application URL, another network, another application on the server, and the server’s relevant services.

Likely investigation areas include an unavailable web service, firewall rule, incorrect port, blocked source IP, failed deployment, or server-level issue. Escalate when every application is affected and the dashboard cannot restore service.

How do you fix DNS_PROBE_FINISHED_NXDOMAIN?

DNS_PROBE_FINISHED_NXDOMAIN means the resolver could not find the requested hostname in DNS. Verify the hostname spelling, authoritative nameservers, A or CNAME records, root-domain configuration, www record, and DNSSEC status.

Cloudways documents that an A record maps the domain to the server’s IPv4 address. Conflicting A, AAAA, or CNAME records can direct visitors to an unintended destination.

How do you fix “This site can’t be reached”?

“This site can’t be reached” is a browser-level message that can represent DNS failure, connection refusal, timeout, TLS failure, or local-network interference. The message alone is not the root cause.

Open the browser’s detailed error, test the Cloudways application URL, run a DNS lookup, check the certificate, and use curl -I to determine whether the failure occurs before or after an HTTP connection.

Why Is Your Cloudways Website Loading Slowly?

A slow Cloudways website is usually caused by resource saturation, inefficient application behavior, cache misses, database latency, external dependencies, or a combination of those factors. The correct response is to correlate the slow period with server metrics and request-level evidence before optimizing or scaling.

Cloudways Monitoring supports CPU, RAM, disk I/O, network, swap, PHP-FPM, database connections, and other application-level statistics, depending on the selected stack.

→ Explore Cloudways Monitoring

Distinguish resource shortage from inefficient application behavior

A server can be genuinely undersized, but an inefficient plugin can also consume every additional resource you add.

For example, a plugin that runs a full-table database query on every page view may saturate a 2 GB server. Scaling to 4 GB may delay the failure without correcting the query.

Use this distinction:

Cloudways defines inodes as pointers to files and directories and warns that reaching the inode limit prevents new file creation and can cause server malfunction. Its documentation recommends df -i and directory-level analysis to locate excessive files.

Check CPU and RAM utilization

CPU saturation means active processes are competing for execution time. RAM pressure can push the server toward swap, slow workers, or failed processes.

Correlate high utilization with:

• Traffic spikes
• Bot requests
• PHP-FPM activity
• Database processes
• Backups
• Image optimization
• Imports and exports
• Malware scanning
• Search indexing
• Cron activity
• Deployment events

Do not use one short spike as proof that the server is undersized. Review a wider period and compare it with the same time on previous days.

Check disk space and inode usage

Disk capacity measures stored data volume. Inode capacity measures the number of filesystem objects.

A server may have free storage but no remaining inodes because millions of cache, session, log, or temporary files exist. Conversely, a small number of large backup archives can exhaust disk capacity without exhausting inodes.

Useful commands include:

df -h
df -i

Delete files only after identifying their purpose, retention requirements, and owner. WooCommerce sessions, current application logs, and active cache directories should not be removed indiscriminately.

Check PHP-FPM pressure and long PHP requests

PHP-FPM manages PHP worker processes. When all available workers are busy, new dynamic requests wait or fail.

Investigate:

• Slow WordPress hooks
• Long database queries
• External API calls
• Heavy page builders
• Uncached search pages
• Large imports
• Checkout and account requests
• REST API activity
• admin-ajax.php
• WordPress Heartbeat
• Repeated bot requests

Cloudways application monitoring includes PHP analytics, while PHP logs can expose files, routes, CPU, and memory activity.

Check database connections and slow queries

Database pressure can appear as slow pages, 500 errors, 502 errors, 503 errors, or “Error establishing a database connection.”

Look for:

• Connection spikes
• Locked or long-running queries
• Unindexed queries
• Large autoloaded options
• Expensive product filtering
• Search requests
• Session-table growth
• Action Scheduler backlog
• External integrations writing repeatedly
• Backup or reporting queries

A database optimization plugin should not be the first response to an unknown database problem. Capture the slow query or table-growth evidence first.

Audit cron jobs and scheduled actions

Cron jobs automate recurring work. A poorly timed backup, export, feed generator, or cache preloader can saturate resources at predictable intervals.

Cloudways provides a Running Crons monitoring view. WooCommerce Scheduled Actions records background tasks such as payment processing, order notifications, and other extension workflows.

For WooCommerce, review:

WooCommerce → Status → Scheduled Actions

Filter for:

• Failed actions
• Past-due actions
• Long-running actions
• Repeated hook names
• Large pending queues
• Payment or subscription tasks
• Email and webhook tasks

Clear Cloudways caches in the correct order

A Cloudways WordPress request may pass through several cache layers:

1. Browser cache
2. WordPress or Breeze page cache
3. Varnish
4. Redis object cache or Object Cache Pro
5. Cloudflare or another CDN

Clear the narrowest relevant layer first. Then retest before clearing the next layer.

For example, if a corrected product price appears in wp-admin but not on the public product page, purge the page cache and Varnish before flushing Redis. Redis may contain valuable database objects unrelated to the stale page.

Cloudways documents Breeze cache purging, Varnish integration, and Cloudflare cache purging through Breeze.

The Cloudways Breeze optimization guide explains how to configure cache exclusions, file optimization, preloading, and WooCommerce-safe behavior.

Troubleshoot WooCommerce-specific performance

WooCommerce cart, checkout, My Account, and session-dependent pages should normally remain dynamic. Aggressively caching those paths can show incorrect carts, stale account information, or failed checkout behavior.

Investigate:

• Cart and checkout cache exclusions
• Session cookies
• Payment API latency
• Webhook failures
• Inventory updates
• Action Scheduler
• Subscription renewals
• Product-filter queries
• Search and variation queries
• Database connection pressure
• Object-cache compatibility
• Third-party tracking scripts

WooCommerce documentation confirms that scheduled actions support background tasks related to payment processing and order notifications and provides logs for failed actions.

Check third-party scripts and external APIs

A Cloudways server can remain healthy while the page waits for an external service.

Common dependencies include:

• Payment gateways
• CRM APIs
• Analytics scripts
• Advertising networks
• Live chat
• Maps
• Fonts
• Product feeds
• License servers
• Shipping calculators
• Email APIs

Use the browser Network panel to sort by duration and identify the slow domain. For server-side calls, inspect PHP logs and application-level traces.

Optimize before vertically scaling

Vertical scaling can be appropriate when sustained legitimate traffic exceeds current capacity. Scaling is not the preferred first response when a single plugin, bot, cron job, or database query causes the spike.

Use a two-stage decision:

1. Remove avoidable load. Fix inefficient code, cache misses, bots, cron overlap, and database issues.
2. Scale verified demand. Increase capacity when the optimized application still requires additional resources.

The Cloudways vertical scaling guide explains provider-specific scaling restrictions and rollback considerations.

[Insert image: Cloudways Monitoring charts showing CPU, RAM, disk I/O, database connections, and a recurring spike | Alt text: “Analyze Cloudways high CPU and memory usage”]

How Do You Troubleshoot Cloudways DNS, Domain, and SSL Problems?

DNS troubleshooting on Cloudways involves confirming that the domain resolves to the intended server before diagnosing WordPress or SSL behavior. Once DNS is correct, verify the certificate hostname, HTTPS redirect path, Cloudflare mode, WordPress URLs, and mixed-content resources in that order.

The Cloudways DNS configuration guide provides a complete record-management workflow for root domains, www, subdomains, mail records, and DNS providers.

Compare the domain with the Cloudways application URL

Use the Cloudways application URL as the control test:

• Application URL works; domain fails: DNS, SSL, CDN, or domain mapping.
• Both fail: Application, server, or platform.
• Domain loads the old website: DNS still points to the previous host or an edge cache remains active.
• HTTP works; HTTPS fails: Certificate, hostname, proxy, or HTTPS redirect.
• Root works; www fails: Missing or incorrect www record.
• www works; root fails: Missing or incorrect root record.

Cloudways documents A records as the mechanism that maps a domain to the intended server IPv4 address.

Check the A and CNAME records

Confirm:

• The root domain points to the intended Cloudways server or current Cloudways-provided target.
• The www hostname points to the intended canonical host.
• Old A, AAAA, or CNAME records do not conflict.
• The domain has been added correctly inside Cloudways.
• DNS changes were made at the authoritative DNS provider.
• Cloudflare proxy settings match the intended troubleshooting test.

Cloudways product workflows may use different record targets. For example, current Cloudways Autonomous documentation can provide CNAME-based targets, while Flexible server setups commonly use server-IP mapping. Always follow the target displayed in the current application dashboard.

Point Your Domain and Configure SSL on Cloudways

This walkthrough shows where domain and SSL settings are located inside Cloudways and how the normal configuration process should work. Use it as a visual reference when diagnosing incorrect DNS targets, hostname mismatches, failed HTTPS connections, or certificate configuration problems.

Video: “How to Point Domains and Install SSL Certificates on Cloudways | Cloudways 101” by Cloudways.

Account for DNS propagation and resolver caching

DNS changes do not become visible to every resolver simultaneously. TTL values, recursive-resolver caches, local operating-system caches, and browser caches can temporarily return different answers.

Check several public resolvers before changing the record again. Repeatedly editing DNS during propagation can create a moving target and extend uncertainty.

Troubleshoot an SSL certificate that is not working

Check:

1. Does the certificate include the exact hostname?
2. Is the certificate expired or not yet valid?
3. Does the certificate chain validate?
4. Does the domain resolve to the server where the certificate is installed?
5. Does Cloudflare connect to the origin using a compatible mode?
6. Is an old certificate cached at a proxy or load balancer?
7. Are root and www both covered?
8. Is the WordPress Address configured for the intended HTTPS hostname?

The install an SSL certificate on Cloudways guide covers standard and wildcard issuance, validation, HTTPS enforcement, and renewal checks.

Troubleshoot a failed Let’s Encrypt wildcard certificate

Let’s Encrypt wildcard issuance requires DNS-based validation. Let’s Encrypt documents that DNS-01 proves control by placing a validation value under _acme-challenge, and Cloudways currently uses DNS authentication with a required CNAME workflow for its wildcard process.

Verify:

• The _acme-challenge CNAME exists.
• The value exactly matches Cloudways’ supplied target.
• The record is publicly resolvable.
• The validation record is not incorrectly proxied.
• Old conflicting validation records are removed.
• The record remains available for renewal.
• The domain is using the nameservers where the record was created.

Cloudways identifies a missing _acme-challenge CNAME as a reason wildcard auto-renewal can fail.

Fix HTTPS redirect loops with Cloudflare

A redirect loop is usually created by conflicting instructions at Cloudflare, Cloudways, WordPress, or the origin web server.

“Cloudflare recommends not performing redirects at your origin web server, as this can cause redirect loop errors.”

— Cloudflare, Inc., SSL/TLS documentation, 2026

The practical lesson is to assign canonical redirect responsibility deliberately. Avoid enabling overlapping HTTP-to-HTTPS and root-to-www rules in Cloudflare, Cloudways, WordPress plugins, and .htaccess simultaneously.

The Cloudways Cloudflare Enterprise guide explains proxy activation, DNS targets, caching, SSL, and troubleshooting boundaries.

[Insert image: Cloudflare SSL/TLS encryption mode beside Cloudways HTTPS settings | Alt text: “Compare Cloudways SSL and Cloudflare redirect settings”]

Fix mixed-content warnings

Mixed content occurs when an HTTPS page requests one or more resources over HTTP.

Inspect the browser Console and Network panels for insecure:

• Images
• Stylesheets
• Scripts
• Fonts
• Iframes
• API endpoints
• Hard-coded theme assets
• Database URLs

Update the source URLs, run a controlled search-and-replace when necessary, clear caches in order, and verify the page again. Cloudways documents clearing Varnish, Breeze, application, and object caches after correcting mixed-content URLs.

→ Evaluate Cloudways Hosting

How Do You Troubleshoot WordPress Application Problems on Cloudways?

WordPress troubleshooting on Cloudways isolates failures in plugins, themes, PHP execution, application files, permissions, rewrite rules, scheduled tasks, REST requests, and the database. Start with logs and recent changes, reproduce the failure in staging, and avoid broad production changes until the affected component is identified.

The WordPress troubleshooting checklist provides a broader CMS-level process that can be used alongside Cloudways monitoring.

Fix the WordPress white screen of death

A white screen often indicates a PHP fatal error, exhausted memory, plugin conflict, theme conflict, corrupted code, or server-level failure.

Use this sequence:

1. Check whether wp-admin still loads.
2. Review Cloudways application logs.
3. Enable logging without displaying errors publicly.
4. Identify the failing file, plugin, theme, or function.
5. Roll back the recent update.
6. Test the correction in staging.
7. Disable debugging after the investigation.

Cloudways lists PHP code errors, memory exhaustion, plugin or theme incompatibility, corruption, and server issues among common causes.

Enable WordPress debugging safely

WordPress documents WP_DEBUG as its built-in debug-mode constant but advises against using visible debugging tools on live sites.

For temporary production logging, a safer configuration is:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Remove or disable debugging after capturing the error. Debug logs may expose file paths, queries, plugin names, personal data, or secrets if left publicly accessible.

Diagnose plugin and theme conflicts

Use recent-change evidence first. If the site broke immediately after one update, deactivate that component before disabling the entire plugin stack.

When wp-admin is unavailable, use SFTP or SSH:

1. Connect to the application.
2. Open public_html/wp-content/plugins/.
3. Rename the suspected plugin directory.
4. Reload the failing URL.
5. Restore the directory name after testing.
6. Replace, update, or report the confirmed plugin.

WordPress documents folder renaming and database-based methods for deactivating plugins when administrative access is unavailable.

For a live WooCommerce store, disabling all plugins can interrupt checkout, payment gateways, shipping, tax, and inventory operations. Clone the application to staging whenever the incident permits controlled testing.

Fix WordPress admin login failures

Check:

• Correct login URL
• Browser cookies
• Security-plugin lockouts
• HTTP authentication
• User role and account status
• Database user records
• Redirect loops
• SSL hostname
• Cache rules
• Recent migration or restore

Cloudways notes that platform-displayed WordPress credentials can become outdated after a third-party database restore or migration. Resetting the application admin password can synchronize usable credentials.

Fix a corrupted .htaccess file

A .htaccess problem can cause 404, 500, redirect, authentication, or access errors on stacks that use Apache-compatible rewrite rules.

First, confirm that your Cloudways stack supports .htaccess. Cloudways’ 2026 migration documentation distinguishes its Hybrid Stack, which uses Nginx and Apache and supports .htaccess, from the Nginx-only Lightning Stack, which does not.

Do not assume that editing .htaccess can solve a rewrite problem on an Nginx-only stack.

Fix incorrect file and folder permissions

Use Cloudways’ permission-reset tool before applying manual recursive permission changes. Cloudways documents that its reset applies to the application webroot and lets the user select application or master ownership.

Permission errors commonly appear as:

• Permission denied
• 403 Forbidden
• Failed uploads
• Failed extraction
• Unable to create directory
• Failed plugin update
• Unable to modify a file

If resetting permissions does not help, inspect application ownership, deployment methods, security rules, and affected paths.

Fix PHP memory exhaustion

A PHP memory error usually names the consumed and permitted memory values in the log.

Do not increase memory first without identifying the process. A faulty plugin can consume any expanded limit.

Use this order:

1. Locate the fatal error.
2. Identify the plugin, theme, or request.
3. Reproduce the request.
4. Optimize or replace the component.
5. Increase memory only when the legitimate workload requires it.
6. Monitor utilization after the change.

Check missing PHP extensions or incompatible PHP versions

A PHP upgrade can expose deprecated functions, missing extensions, or plugin incompatibilities.

Review:

• PHP fatal-error text
• Plugin and theme requirements
• Required extensions
• Composer dependencies
• Database-driver requirements
• Staging behavior on the target PHP version

Test PHP changes in staging before production. Avoid downgrading PHP indefinitely to preserve an abandoned plugin.

Fix failed WordPress core, plugin, or theme updates

A failed update can leave incomplete files or maintenance mode.

Check:

• Available disk space and inodes
• File ownership
• Network connectivity
• PHP errors
• .maintenance file
• Partial plugin directory
• Backup availability

Cloudways documents that interrupted WordPress updates can leave the site stuck in maintenance mode.

Troubleshoot REST API and loopback failures

WordPress uses loopback requests to communicate with itself for WP-Cron, scheduled posts, and safety checks during plugin or theme edits.

Check:

• WordPress Site Health
• DNS resolution from the server
• SSL verification
• Basic authentication
• Security-plugin restrictions
• Cloudflare rules
• Disabled REST endpoints
• Redirect loops

A loopback failure can also delay scheduled actions even when public pages appear normal.

Fix “Error establishing a database connection”

Check whether the failure affects one application or every application.

For one application:

• Verify database credentials in wp-config.php.
• Check whether the database was restored or migrated.
• Inspect database tables.
• Confirm the application’s database user.
• Review the exact database error.

For every application:

• Check database-service status.
• Review server resource pressure.
• Inspect disk and inode capacity.
• Check database connection metrics.
• Escalate repeated database-service failure.

Avoid repairing tables or changing credentials until the error log establishes what failed.

How Do You Troubleshoot a Failed Cloudways WordPress Migration?

Cloudways migration troubleshooting verifies source access, destination credentials, available resources, password protection, transfer completion, database replacement, media integrity, cache state, and DNS timing. The migrated application should be tested through its Cloudways URL before the production domain is switched.

The Cloudways WordPress migration guide provides the complete migration workflow, while this section focuses on failure recovery.

See the Correct Cloudways WordPress Migration Workflow

Before diagnosing a failed transfer, review how the official Cloudways migration process should work from beginning to end. The video demonstrates the WordPress Migrator plugin, required destination information, transfer process, and available migration methods.

Video: “How to Migrate Your WordPress Site to Cloudways | Cloudways 101” by Cloudways.

Diagnose common Cloudways migration failures

Verify SFTP credentials manually

Before retrying the migrator, confirm that the same host, port, username, and password work in an SFTP client.

Cloudways documents SFTP failures as potentially related to network, credentials, client configuration, or IP access restrictions.

[Insert image: Cloudways Access Details beside an SFTP client connection window | Alt text: “Verify Cloudways migration SFTP credentials”]

Remove password-protection barriers

“Turn off HTTP authentication on both the source and destination sites before running the migration.”

— Syed Abuzar Mehdi, Cloudways Help Center author, 2026

Cloudways also recommends temporarily disabling frontend password-protection plugins that block the migrator. Re-enable protection only after the transfer and validation are complete.

Check disk, inodes, and oversized data

A large media library, backup archive, log directory, or database can cause migration delays.

Before retrying:

• Remove obsolete local backup archives from the migration source.
• Confirm destination disk space.
• Check inode availability.
• Exclude irrelevant cache and temporary directories where supported.
• Compress or transfer exceptional files separately.
• Run database cleanup only with a verified backup.

Test the migrated site before changing DNS

Cloudways recommends checking pages, plugins, themes, and media on the destination, clearing Breeze and Varnish, and updating DNS only after the migrated application works.

Test:

• Homepage and key landing pages
• WordPress login
• Forms
• Search
• Media
• Redirects
• Cart and checkout
• Customer accounts
• Payment gateway
• Webhooks
• Email
• Scheduled actions
• API integrations
• Structured data
• Robots directives
• Canonical tags

Do not cancel the old hosting account until DNS has switched and the latest production data is confirmed on Cloudways. Cloudways warns that orders, uploads, and customer data created on the old server will not automatically appear on the migrated server.

Use a 72-hour post-migration monitoring plan

First 0–2 hours

• Confirm DNS answers
• Test SSL
• Test homepage, login, forms, cart, and checkout
• Review error logs
• Monitor CPU, RAM, and database connections

First 2–24 hours

• Check transactional email
• Verify webhooks and scheduled actions
• Inspect media and redirects
• Confirm analytics and tag firing
• Review crawl access and robots rules

First 24–72 hours

• Compare uptime and performance
• Check Search Console crawl signals
• Audit 404 errors
• Review payment and order logs
• Confirm backups
• Monitor recurring cron jobs
• Keep the old server available for controlled recovery

How Do You Use Cloudways Logs and Monitoring to Find the Root Cause?

Cloudways logs and monitoring identify the root cause by connecting an exact failure timestamp with the request, PHP process, web-server response, resource spike, database activity, or scheduled task occurring at that moment. Cloudways application logs record web requests and application errors that can help identify failing files, PHP processes, routes, plugins, and server responses.

Cloudways documents platform-based and SSH/SFTP-based log access, with product-specific instructions for Flexible and Autonomous environments.

The how to access Cloudways through SSH and SFTP guide covers credentials, IP access, SSH keys, SFTP clients, and command-line access.

Connect to Cloudways Through SSH or SFTP

Advanced Cloudways troubleshooting often requires access to application files, historical logs, or the command line. This official tutorial shows how to locate the correct credentials and connect securely through FileZilla, PuTTY, or a terminal.

Video: “How to Connect to Your Application Using SSH or SFTP on Cloudways” by Cloudways.

Which Cloudways logs should you inspect?

Cloudways explains that Apache access logs relate to dynamic PHP requests, Nginx logs to static assets, and PHP logs to process-level files, routes, CPU, and memory information in its documented stack model.

Correlate timestamps instead of scanning randomly

Use this workflow:

1. Reproduce the error once.
2. Record the exact time and timezone.
3. Filter logs around that time.
4. Identify the request path.
5. Match the request to the PHP, web-server, or database error.
6. Check monitoring graphs for the same minute.
7. Review the most recent deployment or update.
8. Test one corrective action.
9. Reproduce the original request.
10. Record the result.

Timezone mismatches can create false conclusions. Cloudways restore points, for example, are documented in UTC, so convert incident times before choosing a restore point.

Use Cloudways Copilot without overrelying on automation

As of August 3, 2026, Cloudways describes Copilot as an AI-powered monitoring and troubleshooting assistant that generates issue-specific insights and offers SmartFix for supported problems. Cloudways also announced application-level 5xx diagnostics in June 2026.

Cloudways documents SmartFix support for selected disk, inode, host-health, backup, and web-stack issues. The dashboard shows proposed actions before execution, but Cloudways also states that some complex issues still require manual intervention.

Before applying an automated fix:

• Read the proposed operations.
• Confirm the affected server.
• Check backup availability.
• Preserve the insight ID.
• Verify the issue after execution.
• Investigate recurrence.
• Contact Support if SmartFix fails or the same insight returns.

Copilot plans, credits, supported fixes, and eligibility can change. Verify the current dashboard and Cloudways billing documentation immediately before publishing commercial details.

[Insert image: Cloudways Copilot insight with root cause, recommended action, and SmartFix review screen | Alt text: “Review Cloudways Copilot troubleshooting insight before SmartFix”]

Example Cloudways incident timeline

09:02 UTC: Uptime monitor detects 503 on checkout.

09:04 UTC: Homepage works; checkout and account pages fail.

09:07 UTC: Monitoring shows PHP pressure and rising database connections.

09:10 UTC: WooCommerce Scheduled Actions contains thousands of overdue tasks from one extension.

09:14 UTC: Extension’s background process is paused.

09:18 UTC: Checkout returns 200 and test payment succeeds.

09:30 UTC: Failed-action logs identify the extension update that created duplicate jobs.

10:15 UTC: Fix is tested in staging and deployed.

Next day: Alerting is added for failed scheduled-action growth.

The timeline separates detection, mitigation, root-cause confirmation, recovery, and prevention. This structure prevents a temporary restart from being recorded incorrectly as a complete resolution.

Which Cloudways Troubleshooting Tools Should You Use?

The best Cloudways troubleshooting tools combine infrastructure monitoring, application logs, browser diagnostics, DNS and SSL validation, WordPress testing, uptime monitoring, and secure server access. Use each tool to answer a specific diagnostic question rather than collecting unrelated reports.

WordPress Site Health includes tests for loopback requests, debug mode, environment information, plugins, and related site conditions.

[Insert image: WordPress Site Health status showing REST API and loopback test results | Alt text: “Check WordPress Site Health on Cloudways”]

[Insert image: Browser developer tools Network panel sorted by request duration | Alt text: “Find slow Cloudways requests with browser developer tools”]

[Insert image: Terminal showing curl headers, redirect chain, dig output, disk usage, and inode usage | Alt text: “Run Cloudways troubleshooting commands in terminal”]

[Insert image: SSL validation report showing hostname, chain, and expiration details | Alt text: “Verify Cloudways SSL certificate hostname and chain”]

Practical Cloudways troubleshooting scenarios

A prospective customer evaluating operational tooling can compare Cloudways hosting plans after reviewing whether Flexible, Autonomous, monitoring, support, and Copilot capabilities match the application’s requirements.

→ Compare Cloudways Hosting Plans

When Should You Restart Services, Restore a Backup, Scale the Server, or Contact Support?

Restart services when a confirmed backend process is unresponsive, restore a backup when a known change caused a reproducible failure, scale when optimized legitimate demand exceeds capacity, and contact Cloudways Support when server-level recovery remains unsuccessful or unsafe. Each action addresses a different class of evidence.

When should you restart Cloudways services?

Restart a service when:

• Its dashboard status shows failure.
• Logs indicate that the process stopped responding.
• Every application depending on the service fails.
• Resource usage has returned to safe levels.
• A configuration change requires a controlled restart.

Do not repeatedly restart Nginx, Apache, PHP-FPM, Varnish, Redis, or the database without recording what caused each failure. Recurring service crashes usually indicate an unresolved resource, configuration, code, disk, inode, or traffic problem.

When should you restore a Cloudways backup?

A Cloudways backup restore returns application files, a database, or both to an earlier saved state and should be considered when a recent change caused a reproducible failure.

Restore when:

• A deployment corrupted production.
• A plugin update broke the site.
• Files were deleted.
• A database change caused known damage.
• Manual repair would be slower or riskier.
• The correct restore point is verified.

Cloudways Flexible documentation describes complete and partial restore options, including files-only and database-only restoration. Cloudways also creates a pre-restore backup that can support rollback of the restore operation.

However, Cloudways’ current Point-in-Time Restore article contains inconsistent wording about the available Autonomous restore scope: one section says Autonomous supports only full restore, while a later workflow describes complete, files, or database choices. Verify the controls shown in the live dashboard or confirm with Cloudways Support before planning an Autonomous partial restore.

Use the Cloudways backup and restore guide to configure backup frequency, retention, on-demand backups, restore-point selection, and recovery testing.

When should you vertically scale a Cloudways server?

Vertical scaling on Cloudways involves increasing the server’s computing capacity while preserving its applications, data, and configuration.

Scale when:

• Legitimate traffic remains high after optimization.
• CPU or RAM pressure is sustained.
• Database demand is confirmed and valid.
• The application has outgrown its current plan.
• A planned event requires temporary or permanent capacity.
• Sufficient storage is required for a controlled restore.

Cloudways documents provider-specific restrictions. Some server families cannot be directly scaled down, storage reductions may require cloning, and the server may briefly go offline during scaling. Cloudways recommends an on-demand backup and off-peak execution.

When should you contact Cloudways Support?

Contact Cloudways Support when:

• Every application on a server remains unavailable.
• A backend service repeatedly crashes.
• The database service cannot recover.
• Filesystem corruption is suspected.
• Disk or inode cleanup is unsafe.
• A restore or rollback fails.
• A server becomes inaccessible.
• A platform or provider problem is suspected.
• SmartFix fails.
• Downtime persists without a clear application cause.

Cloudways currently directs users to its Support Center, dashboard chat, and support-ticket system.

Cloudways Support escalation template

Subject: Production incident – [domain] – [error or symptom]

Cloudways account:
Server name and ID:
Application name and ID:
Affected domain:
Cloudways product: Flexible / Autonomous
Incident start time and timezone:
Last known working time:
Current error:
Affected URLs:
Affected users or regions:
Business impact:

Recent changes:
- Plugin/theme updates:
- Deployment:
- PHP/database changes:
- DNS/SSL/CDN changes:

Evidence:
- Relevant log excerpts:
- CPU/RAM/disk/inode graphs:
- Database connection graph:
- Screenshots:
- Copilot insight ID:

Troubleshooting completed:
1.
2.
3.

Current result:
Requested assistance:

A concise incident summary reduces repeated questions and gives Support a reproducible starting point.

What Should You Do Next to Prevent Recurring Cloudways Problems?

The next step after recovery is to convert the incident into a repeatable prevention workflow that covers backups, staging, monitoring, change control, documentation, and escalation. A website is not fully recovered until the root cause is documented and controls are added to reduce recurrence.

Build a Cloudways incident-prevention workflow

1. Configure automated server-level backups.
2. Create an on-demand backup before updates and deployments.
3. Test plugin, theme, PHP, and code changes in staging.
4. Use external uptime monitoring.
5. Record baseline CPU, RAM, database, disk, inode, and traffic levels.
6. Maintain an incident log.
7. Document DNS ownership, nameservers, and record purposes.
8. Audit cron jobs and WooCommerce Scheduled Actions.
9. Remove abandoned plugins and themes.
10. Review resource-intensive plugins.
11. Keep escalation contacts and access credentials current.
12. Review Cloudways Copilot insights where available.
13. Test backup restoration periodically.
14. Add post-deployment checks for forms, checkout, email, APIs, and logs.
15. Conduct a brief post-incident review after every material outage.

Use a lightweight change-management rule

Every production change should record:

• Change owner
• Date and time
• Reason
• Files or settings affected
• Backup or restore point
• Validation steps
• Rollback method
• Result

For example, a plugin update record should identify the previous version, new version, staging result, deployment time, and rollback package.

Create measurable alert thresholds

Set alerts around business-relevant conditions rather than every short spike.

Useful signals include:

• Repeated 5xx responses
• Sustained CPU pressure
• Low disk capacity
• High inode usage
• Database connection saturation
• Failed checkout
• Failed scheduled actions
• Backup failure
• SSL expiration risk
• DNS change
• Uptime failure

Cloudways’ alert behavior and available thresholds may change by product and platform update, so verify the current monitoring and Copilot controls before documenting an internal standard.

Readers whose required server control, support model, application compatibility, or scaling behavior remains unmet can compare the best Cloudways alternatives after completing the technical diagnosis.

Conclusion: How Should You Troubleshoot Cloudways Methodically?

Cloudways should be troubleshot by verifying the incident scope, checking platform status, isolating the failing layer, examining logs and monitoring, applying the lowest-risk corrective action, validating recovery, and documenting the root cause. This evidence-based sequence is safer and more reliable than randomly clearing caches, changing DNS, scaling resources, or restoring backups.

Start with the simplest discriminator: one user, one domain, one application, one server, or the entire platform. Then preserve the evidence, reproduce the failure, correlate the timestamp, and change only one relevant variable.

A reusable incident-response checklist turns Cloudways troubleshooting from an emergency reaction into a controlled operational process.

→ Start Cloudways Hosting

Cloudways Troubleshooting FAQs

Cloudways troubleshooting FAQs address edge cases involving cache purging, DNS timing, debugging, scaling, database failures, and service restarts.

Can clearing the cache fix a Cloudways 502 error?

Clearing Varnish may remove a cached 502 response after the underlying service or application problem has been fixed. Cache purging does not repair a failed PHP-FPM process, overloaded server, plugin conflict, or database problem.

Should you enable WP_DEBUG on a live Cloudways website?

Avoid displaying WordPress debug output publicly. When production logging is necessary, direct errors to a protected log, disable public display, collect the required evidence, and turn debugging off after diagnosis. WordPress warns that visible debug information can expose sensitive details.

How long does a Cloudways DNS change take?

DNS visibility depends on the record TTL, authoritative nameserver update, recursive resolver, local cache, and browser behavior. Check several independent resolvers before changing the record again.

Is vertical scaling always the best fix for high CPU?

No. Scaling is appropriate for sustained legitimate demand after avoidable application load has been addressed. A faulty plugin, runaway cron job, bot surge, or inefficient query should be corrected before scaling.

How can you tell whether a database error is application-level or server-level?

Test another application on the same server. One failing application suggests credentials, tables, or application configuration; every database-dependent application failing suggests a shared database service, server resource, disk, or infrastructure problem.

Should you restart every Cloudways service after an error?

No. Restart only the service that evidence shows is failed or unresponsive. Broad restarts may interrupt healthy applications and remove useful diagnostic evidence.

What should you send to Cloudways Support?

Send the server and application identifiers, affected domain, error, incident time and timezone, affected URLs, recent changes, relevant log excerpts, resource graphs, Copilot insight ID, troubleshooting steps, and business impact.

References

The references below are the first-party documentation and standards sources cited throughout this guide.

• Cloudflare, Inc. (2026). Always Use HTTPS. Cloudflare SSL/TLS Documentation.
• Cloudflare, Inc. (2026). ERR_TOO_MANY_REDIRECTS. Cloudflare SSL/TLS Documentation.
• Cloudways. (2026). Cloudways Copilot now detects and troubleshoots critical application-level 5xx errors.
• Cloudways. (2026). How to get started with Cloudways Copilot. Cloudways Help Center.
• Cloudways. (2026). How to install Let’s Encrypt SSL certificate. Cloudways Help Center.
• Cloudways. (2026). How to use the Cloudways WordPress Migrator Plugin. Cloudways Help Center.
• Cloudways. (2026). How to do a point-in-time restore of your application. Cloudways Help Center.
• Cloudways. (2025). Guide to scale servers on the Cloudways Platform. Cloudways Help Center.
• Cloudways. (2025). How to monitor server and application resources. Cloudways Help Center.
• Cloudways. (2025). How to resolve 404/Not Found error. Cloudways Help Center.
• Cloudways. (2025). How to fix 413 Request Entity Too Large error. Cloudways Help Center.
• Cloudways. (2024). How to fix 502 Bad Gateway error. Cloudways Help Center.
• Cloudways. (2024). How to resolve 500 Internal Server Error. Cloudways Help Center.
• Cloudways. (2024). How to view application logs via SSH/SFTP. Cloudways Help Center.
• Cloudways. (2024). My server is out of inodes. How do I solve it? Cloudways Help Center.
• Internet Engineering Task Force. (2022). RFC 9110: HTTP Semantics.
• Internet Engineering Task Force. (2012). RFC 6585: Additional HTTP Status Codes.
• Let’s Encrypt. (2026). Challenge types.
• WordPress.org. (2025). Debugging in WordPress. Advanced Administration Handbook.
• WordPress.org. (2018). FAQ troubleshooting. WordPress Documentation.
• WooCommerce. (2026). Scheduled actions. WooCommerce Documentation.