"The server just crashes on startup" is the most common modded Minecraft complaint on any forum, and the usual answers are guesses: add RAM, reinstall, try another pack. We wanted actual data, so we booted the 100 most popular CurseForge modpacks on our own hardware. Every pack that failed got a second, independent attempt, and a failure only counted if it reproduced both times. That last rule mattered: six packs that looked broken on the first try booted fine on the second, including All the Mods 10.
The headline result: 74 of the 100 most popular modpacks boot today. When this sweep started it was 46, with 6 coin-flips and 48 failing both attempts. Then the uncomfortable part: tracing those 48 failures to root causes showed most of them were our fault, not the packs'. Fixing our own pipeline is what moved the number. The causes are not specific to us, which is why they are worth publishing: they are the same reasons modpack servers fail everywhere.
The biggest finding: most packs run at the edge of their memory
Before the failure taxonomy, the number that changed how we think about modded hosting: of the 94 packs that gave us a memory reading, 43 ran at 5 % memory headroom or less. Most of those readings are idle, on a freshly generated world, with zero players connected; ten of the 43 are the moment a pack hit its ceiling and stopped. Eighteen reported 0 % — every megabyte of their limit in use the moment they finished starting. Every reading is published pack by pack.
This explains the most maddening symptom in modded Minecraft: the server that worked yesterday and crashes today. A pack idling at 99 % of its memory limit does not have a stable state; whether it survives startup is decided by garbage-collector timing. Add one player, one chunk generation spike, one busy mob farm, and the same server that booted five times in a row is killed by the out-of-memory reaper on the sixth. If your modded server crashes sometimes, memory margin should be your first suspect, not your last.
The failure taxonomy
Here is what actually killed the reproducible failures, in roughly descending order of frequency.
Client-only mods reaching the server. Modpacks ship in two forms: the client pack players install, and a server pack the author prepares without client-only mods. When the server pack is missing or ignored, client mods land on the server and crash the loader at startup. A subtle version of this: some older packs publish a server pack that tooling silently fails to detect, so the installer falls back to the client files without telling anyone. If your crash log names a mod and that mod is a minimap, a shader, or anything cosmetic, this is your cause.
The wrong loader build. A pack is built against a specific Forge, Fabric, or NeoForge build. Install it on "latest" instead and mixin-heavy packs die in ways that look like random mod bugs. The fix we landed on is the one any admin can copy: the pack's own manifest.json states the loader, its exact build, and the Minecraft version. Trust the manifest, not the listing page, and not "latest."
The wrong Minecraft version. Catalog tags on modpack sites are coarser than the manifest and sometimes plain wrong. Four packs in our sweep failed because the version the listing implied was not the version the pack was built for. Same fix: the manifest is the truth.
"Server packs" that are actually installers. Seven packs shipped a "server pack" that contained no server at all, just an installer script meant to be run by hand. Uploaded to a host expecting ready-to-run files, nothing installs and the server exits immediately. If your server "starts" and dies in under a second with an almost empty log, look at what the pack's zip actually contains.
Plain out-of-memory. Eight packs could not boot at the RAM size recommended for them; one 468-mod monster was OOM-killed at more than 2 GB of unpacked server files. Two traps here from our own log analysis: an exit code 137 is the kernel killing the process for memory, not a mod bug, and we initially misfiled two of these as mod problems. And the scary-looking invalid dist DEDICATED_SERVER line appears on perfectly healthy servers; do not chase it.
Download and packaging failures. The remainder: packs whose files could not be fetched at all, and mislabeled uploads where the "server" file was a client zip. Boring causes, real failures.
What this means when your server crashes
A practical checklist, in order, valid on any host:
- Check the exit. Killed with exit 137 or an OOM line? It is memory. Raise the limit or trim the pack; nothing else will fix it.
- Read the first named mod in the crash. Cosmetic or client-side mod? You are running client files; get the author's server pack.
- Verify loader and version against the pack's
manifest.json, not the site listing. Exact build, not latest. - Look inside the server zip. If it is an installer script, run it locally or find a host that handles that shape.
- Only then suspect the pack itself. In our data, genuinely broken packs were a small minority.
How to actually read a crash log
The taxonomy above says what goes wrong. This is the order to check it in, and the order matters more than the list does, because several of these failures impersonate each other. It is the same precedence our own classifier uses on every crashed container.
1. Was it killed from outside? exit 137. That is not a mod and not a stack trace. It is the kernel's OOM killer stopping the container, so the log often ends mid-sentence with nothing that looks like an error. Anything you find above it is a symptom, not the cause.
2. unable to create native thread is not a memory problem. It arrives as java.lang.OutOfMemoryError, which is exactly why it gets misread. The JVM could not spawn a thread, and that is a process or PID ceiling, not heap. It fires on a box with gigabytes free. This one has to be checked before the heap patterns, because a bare java.lang.OutOfMemoryError at end of line matches those too.
We got this wrong ourselves, and the cost is specific: the panel told people to buy a bigger plan, they bought it, and the limit they were actually hitting did not move.
3. Then the real memory failures. OutOfMemoryError: Java heap space means a bigger heap genuinely helps. OutOfMemoryError: Metaspace is class metadata rather than world data, which large packs hit even when the heap is fine. GC overhead limit exceeded means Java spent nearly all its time collecting garbage and gave up, which is memory pressure wearing a different hat.
4. Java version before anything mod-shaped. Unsupported class file major version and "requires Java 17" are answered by the Java version, and no amount of removing mods will fix them.
5. A ClassNotFoundException is not always a mod. If the server has custom JVM arguments, check those first. An unquoted space in a -D value word-splits, the stray token gets treated as the main class, and the resulting error reads exactly like a failed mod. Sending someone to hunt through mods/ for a typo in a settings field is wrong twice over, and on a server with no mods at all it is wrong three times.
6. Only now blame a mod. ModLoadingException, "missing or unsupported mandatory dependencies", "loading errors have occurred". At this point the name in the trace is usually the real culprit.
7. Address already in use means something else holds the port. Almost always the previous process has not exited yet.
One line that is never the cause
Forge logs invalid dist DEDICATED_SERVER on healthy servers. It looks like an error, it appears near the top of the log, and it means nothing is wrong. We filed it as a root cause twice during this sweep before checking it against servers that were running perfectly. If you are searching a crash log for the first alarming string, this is the one that will waste your afternoon.
The honest conclusion
We ran this sweep expecting to catalogue broken modpacks and mostly catalogued our own bugs. Thirty-eight of the 48 reproducible failures traced to the hosting side: wrong install path chosen, loader build not pinned, version taken from tags instead of the manifest, RAM recommendations too thin. The packs publish the information needed to boot them correctly; the failures came from not reading it.
That is also the takeaway for choosing a host for a modpack: ask how they pick the server files, whether they pin the loader build from the manifest, and what RAM they recommend for your specific pack — and whether that number comes from measurement or from a guess. Our per-pack measurements now drive the RAM recommendations on our modpack pages, and the background on sizing lives in how much RAM a Minecraft server needs.
A modpack server that will not start is almost never a mystery. It is one of six causes, five of which are checkable in ten minutes with the crash log and the pack's manifest in front of you.