The situation first, the repair second
An outage creates pressure, and pressure leads to actions that make things worse. The most common one is restoring a backup immediately: it overwrites the state in which the cause would still be visible, and in a compromise it brings the hole back.
So the same question always comes first: is the server answering at all, is it answering with an error, or is it serving a page that is wrong? Those three cases have nothing to do with each other and lead to three different routes.
The most common emergencies
A blank page or error 500. Usually a consequence of the last change: an extension, an update, a PHP version changed by the host. The cause is almost always in the error log, which does have to be switched on for that.
The backend does not answer while the frontend does. Often a memory or session problem, sometimes an extension that only takes effect in the backend.
Something broke after an update. The case with the clearest way back, provided there is a defined route to the server. Without one it turns into searching through the installation.
Foreign content, redirects or spam from the server. Different rules apply here than for a technical outage, see TYPO3 compromised.
Everything is gone. A deleted page tree, an overwritten database, a lost directory. The only case in which the backup genuinely is the first move, and the case that reveals whether one was ever restored.
The site is running but nobody can reach it. An expired certificate, a wrong DNS record, a block at the host. From outside this looks like a website outage and has nothing to do with the website.
What you can do before anybody looks
Write down what happened last. An update, a new extension, a change at the host, a migration. The time of the last change is the single most valuable piece of information.
Overwrite nothing. No restoring backups, no deleting files, no uninstalling extensions while the cause is unclear.
Collect the credentials. Hosting, FTP or SSH, database, backend. The time otherwise spent on this in the middle of a call-out is the most expensive time of the whole exercise.
If outside access is suspected: change passwords, and not only the one that appears to be affected.
If it has to be quick: 0711 219 55 380 . Everything else is on the contact page.
How we proceed
Reachability from outside first, then a look at the logs, then preserving the state. Only after that does anything change.
For restoring, the shortest defensible route applies. If the site shows a maintenance page for a while in the process, that is not a step backwards; it stops a compromised or faulty version from being served any further.
At the end stands the question of why it happened. Without that answer the call-out is not finished, only interrupted.
Why most emergencies were avoidable
In hindsight nearly every call-out traces back to three things: an installation without security maintenance, a backup that was never restored, and a route to the server nobody can describe.
All three cost little in normal operation and a great deal during an incident. What ongoing care covers is described under TYPO3 maintenance; how long your version still receives security fixes is shown in the version overview and in the guide when support ends.
If you are reassigning maintenance after a call-out, the handover questions are under changing agency.