Support can solve a problem in one reply or ten, and the difference is usually what you send in the first message. This guide is how to ask well — the three things to gather, and an honest line on what support can fix versus what's yours to fix.
| At a glance | |
|---|---|
| Before you ask | Read the console and try the matching guide — half of "bugs" are answered there |
| When you ask | Send shared logs, your server ID, and what you already tried |
First, let the panel answer
Most problems announce themselves in the Console — and the first error, read from the top, is usually the real one. The panel even helps: its smart diagnostics detect missing packages, missing startup files, port conflicts, and version mismatches, often with a one-click fix button. So before you open a ticket:
- Read the console from the top.
- Match the error to a guide — When your server won't start, When dependencies won't install, I can't reach my app, or the other decoders in this section.
- If that doesn't crack it, then escalate — with the three things below.
The three things support needs
1. Shared logs — not a screenshot. The Console page and the Logs page both have a Share button. It packages your logs, redacts secrets automatically, and gives you a link. Send the link. It's more complete than a cropped screenshot and it's already scrubbed, so you're not leaking a token by accident.
2. Your server ID. Support manages a lot of servers — name the exact one. Your server's ID is in its URL in the panel; copy it so there's no ambiguity about which server you mean.
3. What you already tried. This saves an entire round-trip:
| Instead of | Send |
|---|---|
| "my server is broken" | "It won't start. Console says Cannot find module 'express'. I added express on the Packages page and restarted — still failing. Logs: [link]. Server ID: 12345." |
The second version tells support the symptom, the exact error, the fix you already ruled out, and where to look. That's often answerable in one reply.
💡 Tip: The Share link from the console is the single most useful thing you can attach. Grab it first, before you write anything else.
What support can do
Support owns the platform side of the line:
- The node or hardware is misbehaving, or a server is genuinely stuck.
- Billing, plans, and account questions.
- Confirming and escalating an actual platform bug.
- Restoring access when you're locked out.
What support can't (or won't) do
Being honest about this saves everyone time. Support generally won't:
- Write or debug your code, plugin configs, or mod setups — that's the application side of the line, and it's yours. The guides library and each tool's own docs are built for exactly this.
- Recover data you never backed up. There's no undo for files you didn't save — which is why backups matter before something goes wrong, not after.
- Guarantee a specific modpack, plugin, or library works — those are third-party, and compatibility is between you and them.
🎯 Good to know: "Support can't fix my code" isn't a brush-off — it's the same reason a landlord fixes the plumbing but not your furniture. The guides are the manual for the furniture.
If you need a teammate to look
Sometimes the fastest fix is a second person, not a ticket. The Subusers page invites someone by email or username and grants scoped permissions — console-only, files, or a specific area — so a friend can help without full control of your server. You decide exactly what they can touch, and you can remove them anytime. See Give teammates access with sub-users.
Help yourself first, faster
- The Activity page is an audit log of who did what and when — great for "why did this change?" before you even ask.
- Dashboard how-tos (billing, account, panel walkthroughs) live in the Knowledge Base. See the Knowledge Base: kb.falixnodes.net.