Troubleshooting Shopware

Diagnose and fix common Shopware 6 problems on TurboStack, including cache, message queue, OpenSearch indexing, thumbnails, HTTP 500 errors, and logs.

When a Shopware store is not working correctly, the cause is usually a stale cache, a stalled message queue, an indexing issue, or a configuration mismatch. This page shows where to look and how to fix the most common problems on TurboStack.

Where to find the logs

Most answers are in the application log or the web server log. Your app directory is /var/www/<user>/<app>/shopware/ (the <app>/ segment is only present when an app name is set).

Component Where
Shopware application /var/www/<user>/<app>/shopware/var/log/*.log (e.g. prod-*.log)
Nginx access/error host log directory for the vhost (web server logs)
PHP-FPM the PHP-FPM pool log for the runtime
Database (MySQL) the MySQL error/slow-query log on the host
Varnish Varnish runs in front of the storefront when varnish_enabled is set

Also check the host's Health tab for resource pressure and service status. Check recent deploys in History to see whether a change coincides with the problem.

Common issues

Symptom Likely cause Fix
Stale prices, content, or layout Outdated application/HTTP cache Run bin/console cache:clear; if Varnish is on, also invalidate it (purge / cache:clear:http)
Emails, exports, or jobs never run Message-queue worker or scheduled tasks not running Ensure messenger:consume and scheduled-task:run are running; check the Redis transport in .env.local
Search empty or outdated OpenSearch not indexed / disabled With SHOPWARE_ES_ENABLED=1, run bin/console es:index; otherwise run bin/console dal:refresh:index
Missing or broken product images Thumbnails not generated Run bin/console media:generate-thumbnails
HTTP 500 / white screen App error or bad config Read the latest var/log/prod-*.log; verify DATABASE_URL and APP_URL in .env.local, then cache:clear
"Sales channel could not be found" / wrong URLs Sales-channel domain mismatch Make sure the storefront sales-channel URL matches the host's server_name/domain
Redis errors on every page Redis service down or wrong socket Confirm Redis is enabled in Services; check the sockets in config/packages/hostedpower.yaml

A troubleshooting workflow

  1. Check Health - check for CPU, memory, or disk exhaustion and confirm services are up.
  2. Read the relevant log - start with var/log/prod-*.log, then the Nginx and PHP-FPM logs for HTTP 500s.
  3. Review the last deploy - open History; if a recent change broke the site, revert and re-publish from Publishing.
  4. Verify services - confirm MySQL, Redis, the message-queue worker, and Varnish are running in Services; clear the cache and warm it after any fix.

Getting help

If you are still stuck, gather the exact error from the logs, the time it started, and any recent deploy, then reach out via Support. The general platform troubleshooting guide covers host-level issues that affect every application.