LiteSpeed Cache · Help

LiteSpeed: optimised images are never pulled?

Trace the path from QUIC.cloud to the local image and find the missing step between optimisation, retrieval and storage.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

Images marked optimised in QUIC.cloud do not prove successful retrieval by WordPress. Follow one image group through completion, notification, pull and local storage. Compare a single manual retrieval with automatic execution and inspect its matching error. Then check the file actually served to the browser; repeated submission or deleting originals does not establish a repair for an unidentified intermediate failure.

Source basis: Q1 · Q2

Applies to
LiteSpeed Cache with QUIC.cloud image optimisation. The original incident concerns the boundary between completed remote processing and local retrieval, without a conclusively established common cause.
How to verify the result
The selected image group is correctly stored locally and served to the browser; the next automatic run also works if scheduled retrieval was affected.
Your first check

Do images stop before retrieval, or does local processing fail afterward?

Record one image group’s status and timestamps. Observe a single manual pull and its log before resetting queues or original files.

QUIC.cloud reports that images are optimised, but WordPress still waits to retrieve them. Repeatedly pressing Pull Images may not change the status, or only the automatic process may fail. The reviewed incident focuses on this boundary between completed remote processing and local retrieval. Success at the external service does not establish successful storage on the website. Q1

Separate the processing stages

Treat submission, remote completion, notification, retrieval and local processing as distinct stages. LiteSpeed documents pull and cron issues as well as failures involving source files. A single overall status cannot distinguish all of these cases. Q2

Choose one small, identifiable image group as the diagnostic sample. Record its state before requesting it again or changing settings. Preserve original files and existing backups so that investigation does not remove the material needed for recovery.

Follow one stalled group

  1. Confirm remote completion: Match the same group in the plugin and the connected service. Does it belong to the correct website, and is an actual result ready? An earlier successful job does not explain today’s pending entry.
  2. Check notification: Does the website receive the completion message? Compare the plugin log, timestamp and any rejected incoming requests. A protective rule or communication problem becomes a useful lead when there is a matching response, not merely because a firewall exists.
  3. Compare manual and automatic retrieval: Start one supported pull and observe the log. If it works while automatic retrieval does not, investigate scheduled execution. If both fail, enabling a cron option alone is not a demonstrated repair.
  4. Trace local processing: Check the file path, source-file presence, ability to write and exact error. If the original changed after submission, a file-comparison failure is different from a simple connection failure.
  5. Inspect the delivered image: After a successful pull, check both the local file and the resource actually loaded by the browser. An older page or image cache can otherwise make a working change appear ineffective.

Apply the correction at the failing stage

For a missing notification, correct the evidenced communication path. For a job that never runs, investigate the relevant scheduled task. For a file error, work on that path or image group. A global reset of image data will not automatically repair these different causes and may remove useful diagnostic evidence.

After the selected group succeeds, observe one subsequent job before declaring the process recovered. Keep the sample small enough that a remaining fault does not create an unnecessarily large queue or consume avoidable processing resources.

Frequently asked questions

Should I keep submitting the images again?

Not while the missing stage is unknown. Repeated submissions can create more work without repairing local retrieval.

Does one successful manual pull prove everything works?

It confirms that retrieval. Verify the next automatic run separately if automation was the failing part.

Can I delete the original images?

Not as a diagnostic step. They provide the comparison material and may be needed for recovery or another optimisation attempt.

Information for support

Provide the LiteSpeed version, image group identifier, sequence of statuses and redacted log excerpts. Private image contents are unnecessary for the initial technical comparison.

KAN KAI WORKS can trace the optimisation job, notification and local file processing. Get help with this case.

Support with this issue

KAN KAI WORKS can trace the optimisation job, notification and local file processing.

Describe your case →Related service: Websites & CMS

Sources and scope

Sources checked: 5 November 2026. The original incident has not been independently reproduced.