# White screen or "500 Internal Server Error"

> Your site shows a blank page or a 500 error. The reason is in the Logs tab; here is where to look and what usually fixes it.

Source: https://veldhost.eu/docs/white-screen-or-500

Last verified: 2026-11-13

Your site answers, but with an empty white page or **500 Internal Server Error**. The web server reached your app and your app failed while building the page.

## Why it happens

We never print PHP errors into your pages. Visitors would see paths and code, so error display is switched off for every PHP site, and your code cannot switch it back on. A fatal error is written to a log instead. The visitor gets a blank page or a plain 500.

The usual causes:

- **A code or plugin error.** A deploy, an upload or a plugin update brought in code that crashes.
- **Dependencies missing.** Code was uploaded, but Composer has not installed its `vendor/` folder yet.
- **The wrong PHP version.** The code needs a newer or older PHP than the site runs.
- **A setting is missing.** An environment variable the app reads at start-up, such as a database password or `APP_KEY`, is empty or wrong.
- **The app ran out of memory** on one request. See ["Allowed memory size exhausted" / out of memory](https://veldhost.eu/docs/out-of-memory).

## Fix it

1. **Read the error.** Open [Sites](https://manage.veldhost.eu/portal/sites), choose your site, then **Logs**. Set **Level** to **Errors** and the range to **Since last deploy**. Check two sections:
   - **PHP** holds fatal errors from PHP itself, such as `PHP Fatal error: Uncaught Error: Call to undefined function …`.
   - **Application** holds your app's own log: Laravel's `storage/logs/laravel.log`, or WordPress's `wp-content/debug.log` when it exists.

   A row whose **Status** says **Still happening** is your culprit. The message names the file and line. [Reading your site logs](https://veldhost.eu/docs/site-logs) explains the columns.
2. **Did it start with a deploy?** A deploy checks your site right after the switch. If the home page gives a 500 then, the deploy fails at **Checking the site after the switch** and your site goes back to the release it was on. A 500 on other pages, or one that starts later, passes that check. On the **Deploys** tab, the **Live now** strip shows the live release and when it went out. If the errors started then, use **Roll back to …** on that strip. Your files return to the previous release and your database stays as it is. [Approve a release, discard it or roll back](https://veldhost.eu/docs/release-approval-and-rollback) covers both ways back.

   > **Caution:** **Roll back files & database** also replaces your database with the snapshot taken just before that deploy. Anything written since (orders, sign-ups, comments) disappears from the site. We snapshot the current state first, so you can undo it.

   If the deploy also changed the database, use **Roll back files & database** from the deploy's **⋯** menu instead.
3. **Class not found, or `vendor/autoload.php` missing?** Composer has not run on the code that is live. On the **Deploys** tab, press **Build & deploy**. It runs Composer install and, if they are switched on, your migrations. If a migration fails, the deploy is marked failed; the code it built stays live.
4. **A syntax error, or "requires php …"?** Compare the version your code needs with the one under **Configure** → **PHP version**. Pick the right one under **Run on** and press **Switch**. See [Switching PHP versions](https://veldhost.eu/docs/php-versions).
5. **A database or key error** (`SQLSTATE[HY000] [1045] Access denied`, `No application encryption key has been specified`)? Check the values under **Configure** → **Environment variables**. See [Environment variables](https://veldhost.eu/docs/environment-variables).
6. **WordPress, and the Application log is empty?** WordPress logs nothing until you ask it to. In your app: set `WP_DEBUG` and `WP_DEBUG_LOG` to `true` in `wp-config.php` (leave `WP_DEBUG_DISPLAY` off), reload the page, then check **Application** again. Rename a plugin's folder over [SFTP](https://veldhost.eu/docs/ssh-sftp-access) to switch it off.

> **Caution:** Restoring a backup replaces your site's current files and database with the backup's. Anything changed since it was taken is lost from the site.

If nothing else helps and the site was fine yesterday, [restore a backup](https://veldhost.eu/docs/backups-and-restore) from before the problem started.

## Still stuck?

Check the **Web server errors** section on the **Logs** tab too. Then [contact us](https://veldhost.eu/contact) with your site name, the time it started, and the error row from **Logs** (copy the message, not a screenshot).

## Related

- [Reading your site logs](https://veldhost.eu/docs/site-logs)
- ["502 Bad Gateway" after a deploy](https://veldhost.eu/docs/502-after-deploy)
- [Approve a release, discard it or roll back](https://veldhost.eu/docs/release-approval-and-rollback)
- [Switching PHP versions](https://veldhost.eu/docs/php-versions)