Something's down and people are waiting. The instinct is to start changing things at random — restart, reinstall, flip settings — and that's exactly how a five-minute problem becomes an hour. This runbook gives you an ordered process instead: look in the right place, classify the failure in one glance, stop the bleeding, then find the real cause. Work it top to bottom and you'll almost always know what's wrong inside ten minutes.
| At a glance | |
|---|---|
| You need | Any Falix server that just stopped behaving |
| Plan | Any |
| Time | Ten minutes of calm beats an hour of guessing |
The one rule
Change one thing at a time, and read before you touch. Most outages are already explained, in words, at the top of your console. The reason random restarts feel productive is that they occasionally work — but they also erase the evidence you needed. Slow down for sixty seconds first.
Minute 0–2: open the Console and read from the top
Open the Console from your server menu. Two questions:
- Is it actually running? The status bar says. A server showing stopped hasn't crashed in the dramatic sense — it either never started, exited, or was stopped for you (see the free-timer note at the end).
- What was the first error? Scroll to the top of the last start. The first error is almost always the real one; everything below it is fallout. Falix's console also raises smart diagnostics — a missing package, a missing startup file, a port already in use, a runtime-version mismatch — each with a button that jumps straight to the fix. If you see one, take it.
💡 Tip: A server that starts, prints, and then shows stopped with no error hasn't crashed — a script that finishes just exits. A bot or web server stays up because a listener keeps the process alive. If yours exits cleanly, the fix is code that keeps running, not the panel.
Minute 2–5: classify it
Match your symptom to a row. Each points at the guide that carries it to a finish.
| What you see | Most likely | Go to |
|---|---|---|
| Won't start; error at the top of the console | Missing dependency, bad entry file, syntax error | App won't start |
Cannot find module / ModuleNotFoundError |
A package isn't installed | Install failures |
| Starts, runs, then killed with exit code 137 | Out of memory | Out of memory |
| Console looks healthy but the site won't load | Port / bind address / proxy | I can't reach my app |
| Bot is "running" but offline in Discord | Token, intents, or a login error | Bot appears offline |
| Broke right after a deploy | A bad pull or build step | Git deploy failed |
Classifying first is the whole trick. Once you know which kind of failure it is, you stop trying fixes that were never going to work.
Minute 5–7: did anything change?
Outages that arrive out of nowhere usually aren't out of nowhere. Ask what changed just before:
- A deploy? Check the Git page's deploy history — the newest deploy is the prime suspect.
- A package update? A dependency you bumped can break on the next start. See Dependency hygiene.
- A config or file edit? The Activity log is an audit trail of who did what and when — files, settings, backups, network, git. It answers "what did we touch?" precisely.
If nothing changed on your side and it still fell over, treat it as a fresh failure and trust the console error.
Minute 7–10: stop the bleeding, then fix the cause
When people are waiting, restore service first and investigate after — but roll back deliberately, not blindly:
- Undo a bad deploy — a deployment can be pinned back to an earlier commit, putting the working code back while you look into the broken one. See Auto-deploy.
- Undo a bad change to files — restore the last good backup (stop the server first for a clean restore). This is why the backup taken before the change is the one that saves you.
- Test the fix without risking prod — reproduce and repair on a staging instance or a clone, then apply the change to the live server once it works.
Once service is back, finish the job: reproduce the original error, apply the real fix from the guide you landed on above, and confirm with the success signal that guide names.
🎯 Good to know: Keep a "before" backup and your code in Git and almost every incident has an undo button. The owners who panic during an outage are usually the ones with nothing to roll back to — see Backups strategy.
When it isn't you at all
Not every "it's down" is a bug:
- Free session timer ran out. Free servers run on a session timer and stop when it expires — that's expected, not a crash. Extend it and it comes back. See Keeping apps online.
- Free Minecraft idle stop. A free Minecraft server stops about ten minutes after the last player leaves; rejoining or starting it from the panel brings it back. See How free game servers work.