# Troubleshooting Shopware

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](../../platform/hosts/health.md) tab for resource pressure and service status. Check recent deploys in [History](../../platform/hosts/revisions.md) to see whether a change coincides with the problem.

> [!TIP]
> Logs under `var/log/` are rotated automatically. To watch live errors, tail the current `prod-*.log` while reproducing the issue.

## 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](../../platform/hosts/services.md); check the sockets in `config/packages/hostedpower.yaml` |

> [!WARNING]
> Always run `bin/console` commands as the site's system user from the `shopware/` directory. Running them as root can leave cache and log files unwritable by PHP-FPM, producing fresh 500 errors.

## A troubleshooting workflow

1. **Check [Health](../../platform/hosts/health.md)** - 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](../../platform/hosts/revisions.md); if a recent change broke the site, revert and re-publish from [Publishing](../../platform/hosts/publishing.md).
4. **Verify services** - confirm MySQL, Redis, the message-queue worker, and Varnish are running in [Services](../../platform/hosts/services.md); 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](../../platform/support.md). The general [platform troubleshooting](../../platform/troubleshooting.md) guide covers host-level issues that affect every application.

## Related

- [Deploy Shopware](deploy.md)
- [Shopware best practices](best-practices.md)
- [Health](../../platform/hosts/health.md)
- [Support](../../platform/support.md)