Support

The generic "An error occurred / An unexpected error occurred" message you're seeing is Kickstart's fallback error, shown when the AJAX extraction request fails before Kickstart's own code gets a chance to log anything meaningful — which also explains why no log file is being created even with debug mode enabled.

The most common causes we see for this are server-side resource limits being hit during extraction, since unpacking a backup archive is very intensive on disk I/O, memory, and CPU:

• Insufficient free disk space for both the archive and the extracted files.
• Memory or I/O limits imposed by the hosting environment (Cloudways plans do enforce these per-site).
• CPU usage limits (visible via ulimit -t on the server) being exceeded, which can be worked around by lowering the "seconds per step" / batch size setting in Kickstart so each request does less work.

Since we can't be certain which of these applies here without more information, could you please check the following and let us know what you find?

1. Available free disk space on the site.
2. The exact HTTP response for the failed request: open your browser's Developer Tools, go to the Network tab, click Start in Kickstart again, and check the response (status code and body) for the request that fails. This will tell us whether the server is returning an error before Kickstart even runs.
3. Whether Cloudways' server-level PHP/Apache error log (not Kickstart's own log, since none is being created) shows anything at the time you click Start.

This will let us pinpoint whether it's a resource limit, a timeout, or something else entirely.

Thank you for confirming this and for taking the time to test it — that pinpoints it exactly. Cloudflare's security service was blocking the AJAX request that Kickstart's Start button sends, returning its own "Attention Required" block page instead of letting the request through. Kickstart can't parse that page, so it falls back to the generic "An unexpected error occurred" message, and since the request never actually reached Kickstart's own code, no debug log entry was ever written either. This lines up with what you saw in the Network tab (the 403 response with Cloudflare's block page as the body).

As for why this would suddenly start happening after years of working fine: Cloudflare periodically updates its managed WAF rulesets, so a rule that didn't previously match Kickstart's requests can start matching after such an update, with no change needed on your end.

Rather than leaving Cloudflare bypassed for the whole site going forward, you may want to set up a narrower Cloudflare configuration/page rule that only relaxes the security check for requests to your Kickstart file (e.g. matching its URL path), so the rest of the site keeps the full protection. Let us know if you'd like a hand with that, or if anything else comes up during the restoration.