"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 results: 46 packs booted first time, 6 were coin-flips, and 48 failed reproducibly. Then the uncomfortable one: when we traced the 48 failures to root causes, most of them were the host's fault, not the pack's. After fixing our own pipeline and re-running the sweep, 74 of the top 100 boot. The causes we found 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 80 packs that installed successfully, 43 ran at 5 % memory headroom or less. That is idle, on a freshly generated world, with zero players connected. Twelve packs sat at literally 0 % — every megabyte of their limit in use the moment they finished starting.
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.
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.