Only show guides for your app
A calm, ordered process for when your server stops working — read the console, classify the failure in one glance, roll back if players are waiting, then fix the real cause instead of guessing.
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 |
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.
Open the Console from your server menu. Two questions:
💡 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.
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.
Outages that arrive out of nowhere usually aren't out of nowhere. Ask what changed just before:
If nothing changed on your side and it still fell over, treat it as a fresh failure and trust the console error.
When people are waiting, restore service first and investigate after — but roll back deliberately, not blindly:
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.
Not every "it's down" is a bug: