When it breaks: read the symptom, name the cause
Read the symptom before you guess: disk full, port in use, permission denied, an OOM kill and a dead service each have their own message and command.
Nine blocks in, you know how the machine works. Here is the exam, and it is the one you will actually sit: something is broken, the box is telling you about it, and the words are not friendly. Read the symptom. Name the cause. Guessing is free.
What you just learned
Three of those five failures came straight from earlier blocks. Port in use is block 06. Permission denied is block 03. The service that will not start is block 08. Disk full and the OOM kill are the two new ones, and both came with their own command. Nothing else was needed, only the habit of reading the message instead of pasting it.
The most useful thing here is the one that is not a message at all. When a disk fills up, > and cp say nothing whatsoever. Your deploy looks like it worked and the file is empty. That is measured behaviour on a real box, not a warning: it is why df -h is worth running before you believe anything else.
And the general shape: the loudest line is usually not the cause. "Failed to start nginx" is the headline. The cause is three lines above it, quieter, more specific, and usually the first error in the sequence.
Seen on a real server
E: Write error - write (28: No space left on device)- The disk is full, said out loud by apt. dd and tee say 'No space left on device', node throws ENOSPC. The shell's > and cp say nothing at all. Check with df -h.
Memory cgroup out of memory: Killed process 8784 (node)- The OOM killer: the kernel ended your process for memory. dmesg -T shows it, free -h shows how much you have.
Error: listen EADDRINUSE: address already in use 0.0.0.0:3000- Port in use: the copy of the app you forgot was still running. ss -tulpn finds it.