Laravel emergency: urgent help when the application is down

What this page is for

For the case where something is not working right now. Not for the question of whether a rebuild would be sensible, and not for planning the next stage. The other pages cover those.

We have worked with Laravel for years and regularly take on applications other people built. That is why an emergency in somebody else’s code is not a special case for us.

The order we work in

First we take stock. What exactly has stopped, since when, and what changed beforehand? The last change is the cause in the great majority of cases, and asking about it often saves hours.

Then we make the application reachable again. That is deliberately the second step rather than the last. Falling back to the last working state, or running in a reduced mode, is unsatisfying because the cause has not been found yet. For your business it is the difference between an hour and a day.

Only then do we look for the cause, calmly and on a copy rather than on the running system. Logs, the last deployment, the changes to dependencies.

And finally the question of how it got that far. Nearly always something small was missing: monitoring that would have spoken up earlier, a verified backup, a rehearsed way back. Many people skip this last step, which is why the next call comes.

What we need from you

The more of this arrives with the first message, the quicker it goes.

• Access to the server or the hosting account, and to the source code if you have it.
• A description of what does not work, ideally with the exact wording of the error.
• The point at which it last worked.
• What happened between that point and now. Small things count, such as an update at the host or an expired certificate.
• Somebody on your side who is allowed to make decisions.

If access is missing we still start. It simply takes longer, because obtaining it becomes the first step.

If it was a break-in

A compromised system needs a different order from a technical outage. The reflex to delete the unfamiliar files quickly is the most expensive mistake available: it removes the traces rather than the hole, and as a rule the attacker comes back the same way.

What helps is preserving the state before anything is changed, taking the application off the network, and treating every credential as exposed. Only then does the clean-up begin, and from a clean state rather than by deleting things in the running system.

Which holes usually sit behind such cases is in the piece on findings from security audits.

What we do not promise

No round-the-clock standby. A promise meant to hold at night and at weekends needs several people in rotation, and anything else does not survive contact with reality. During normal working hours we are quick to reach, and anyone who needs guaranteed response times settles that under maintenance.

Nor the recovery of data that no longer exists anywhere. What can be reconstructed is something we tell you after the first look, including when the answer is unwelcome.

Once an emergency is over, it pays to look soberly at what was missing. That is a software audit; it takes longer than the call-out itself, but it prevents the next one.