Your Laravel site shows a 500 error and the developer is gone

Laravel runs a large share of custom business sites: booking systems, portals, shops built to order. The agency or freelancer who built yours has often moved on by the time it breaks, and the 500 page tells you nothing by design, because a live Laravel site hides errors from visitors. The real error is written to a file on the server, and reading it is the whole of the diagnosis.

What the 500 page is hiding

Laravel writes every error to a log file inside the site, in a folder called storage/logs, as laravel.log or one file per day. With debugging off, which is the correct setting for a live site, the browser shows only "Server Error" or a plain 500. Do not switch debugging on to see more: on a live site it prints database passwords and keys to anyone who loads the page.

The usual causes

• The host changed the PHP version. Each Laravel release needs a minimum PHP version, and the packages the site depends on set a maximum. A jump past either breaks the site at the first request.
• The settings file is missing or wrong. Laravel keeps its database password, mail settings and encryption key in a file called .env that is never in a backup of the code. After a server move it is the first thing to check, and "No application encryption key" is the clearest sign.
• Permissions. The web server has to be able to write to the storage and bootstrap/cache folders. After a server change or a restore it often cannot, and the log says the file could not be opened.
• A deploy that stopped half way: dependencies not installed, a build step that failed, or a cached copy of the settings that still points at old values.
• The database: a password changed, the database server down, the disk full, or a change to the code that expected a database update nobody ran.
• Not a 500 but close: emails and background jobs that silently stop, because the queue worker or the scheduler is not running after a reboot.

What not to do

• Do not run package updates on the live site to "fix" it. Updating dependencies on a site you do not know is how a 500 becomes a rewrite.
• Do not restore an old backup over a newer database. Orders and sign-ups since then disappear.
• Do not delete folders you do not recognize, such as vendor or storage. Both are needed.
• Do not switch debugging on, for the reason above.

What to send us

• Where it runs: a VPS, Laravel Forge or Vapor, a managed PHP host or shared hosting. The access we need follows from that; for most Laravel sites it is SSH, which the job page walks you through.
• What changed last: an email from the host about PHP, a deploy, a reboot, a password change.
• The log excerpt if you can reach the server, though we read it ourselves once access works.
• Whether you have the code anywhere else, such as a Git repository. It is useful, not required; the running copy is on the server.

When to hand it to us

The site-down fix is the same price on Laravel as on any platform. We read the log, name the cause, fix it with a copy of what we change taken first, and the report says what it was in plain words. Getting an old Laravel version onto a newer PHP, or upgrading the framework itself, is a separate quote; the fix gets the site running on the version it has.

Questions people ask

Do you need my developer's code or help?

No. The running copy of the site is on the server, which is what we work from. A repository is welcome if you have one.

Can you upgrade an old Laravel version?

Not inside the site-down fix, which gets the site running on the version it has. An upgrade is a separate quote once the site is up and we have seen the code.

Is the PHP2Shell patch relevant to my Laravel site?

Yes, it is a PHP fix, not a WordPress one. The patch itself does not break Laravel; a jump to a newer PHP major version can. The update-PHP fix handles both.