A modded server that will not start, or that runs for ten minutes and then dies, is almost never a mystery once you read the right file. The crash report or the console log usually names the problem outright, and most of the work is knowing where to look and what the common failures look like. This post walks the failures that account for most modded crashes, how to spot each one in the logs, and how to tell a config problem from a genuine mod problem.
The first rule saves hours: read the log before you change anything. When a server crashes it writes to the console and to a crash report file, usually under crash-reports/ in the server directory, and often to logs/latest.log as well. Open the newest one and read from the bottom up. The line that matters is rarely the last line. It is usually the first line of the stack trace that mentions a mod by name.
Loader or Minecraft version mismatch
This is the most common reason a server refuses to start at all. Every mod is built for one loader (Forge, NeoForge, Fabric or Quilt) and one Minecraft version, and will not load against the wrong one. A Fabric mod dropped into a Forge server throws. A mod for 1.20.1 on a 1.21 server usually refuses outright.
In the log this shows up as a message about an incompatible or missing loader version, or a mod requiring a Minecraft version that does not match. The fix is to confirm three things line up: the Minecraft version, the loader, and the loader's own build number. A modpack expects one exact loader build rather than whatever the latest Forge happens to be, and installing a newer loader than the pack was built for is a frequent cause of a server that will not boot. If you set the pack up by hand, our modpack server setup guide walks through matching these correctly.
Client and server mod lists that do not match
If the server starts fine but players cannot connect, and the disconnect message mentions mismatched or missing mods, the two mod lists have drifted apart. Most gameplay mods have to be present on both client and server, at the same version, or the connection is refused during the handshake.
The usual causes are a client running a slightly different pack version, or a mod updated on one side and not the other. Some mods are client-only (a minimap, a HUD tweak) and some are server-only, and those are fine to differ, but the rest have to match exactly. The quickest fix is to hand every player the exact same pack version you run on the server, from the same source.
A missing dependency mod
Many mods depend on a library or API mod to function, and if that dependency is absent the log says so clearly, usually as a line about a mod requiring another mod that is not present.
The log names both the mod that needs the dependency and the dependency it wants, often with a required version. Add the missing library at the version asked for and the error goes away. This is one of the friendliest crashes to fix, because the game does the diagnosis for you.
Running out of memory, and why more is not always the answer
An out-of-memory crash shows up as a java.lang.OutOfMemoryError, often mentioning Java heap space, and tends to happen under load rather than at startup. The reflex is to add more RAM, and sometimes that is genuinely the fix, because modpacks need more heap than vanilla. But a server that ran happily and then started throwing OOM errors after you added a mod is more likely leaking memory than short on capacity.
Adding heap to a leak just makes the crash take longer to arrive. Size the heap correctly first, then watch whether usage climbs steadily and never comes back down, which points at a specific mod rather than a capacity problem. We cover sizing in how much RAM a Minecraft server needs, including why handing the JVM a huge heap can make pauses worse.
A single broken mod, found by bisecting
Sometimes nothing in the log points cleanly at a culprit, or the crash names several mods at once. When you cannot read the answer directly, you find it by halves. Move half the mods out of the mods folder, start the server, and see whether it crashes.
If it still crashes, the culprit is in the half still loaded. If it starts cleanly, the culprit is in the half you removed. Put back half of the suspect group and repeat. Each round halves the number of mods you are testing, so even a large pack narrows to the offending mod in a handful of restarts. It is dull, and it works every time. Be aware that removing a mod others depend on can cause a second, unrelated error, so keep dependency chains together when you split the list.
A corrupted world or chunk
If the server crashes every time it loads, or crashes the moment a player logs in near a particular place, suspect world corruption rather than a mod. A broken chunk or malformed world data crashes the server as soon as it tries to load that region, and the stack trace often mentions chunk loading, region files, or an entity or block entity failing to deserialise.
The safe move is to restore from a recent backup, the fastest clean fix if you have one. Failing that, tools exist to prune or regenerate the damaged region, but they carry their own risk, so back up the world before you touch it. This is the strongest argument for backups on a schedule, because a corrupted world with no backup is the one crash on this list that can cost you the server for good.
Config problem or mod problem
The tell is timing and repeatability. A mod problem usually shows a Java stack trace naming a class and a mod, and it happens consistently at the same point. A config problem is quieter: the server starts, but a value is out of range, two mods fight over the same setting, or a recipe or worldgen entry is malformed, and the log shows a warning or a parsing error rather than a hard crash.
Change one thing at a time. If a crash appeared right after you edited a config file, revert that file before assuming a mod broke. If it appeared after a mod update, treat the mod as the suspect. Modpacks ship with tuned configs for a reason, so a well-built pack that suddenly misbehaves is more often a config edit or version drift than a mod going bad on its own.
Most of this comes down to the discipline the whole stack rewards: read the evidence, change one thing, and confirm before moving on. The pillar guide to running a Minecraft SMP walks that same loop for performance.
If you would rather run a modpack on hardware sized for it, with the loader and memory set up correctly from the start, our modded Minecraft hosting is built for that.