7 Days to Die blood moon and horde lag

A 7 Days to Die blood moon is sized by two numbers: BloodMoonEnemyCount, the zombies alive at once per player, and MaxSpawnedZombies, the ceiling for the whole server. Four players at the default 8 means 32 zombies at a time, replaced as they die from 22:00 until 04:00. When horde night lags, the cause is almost always one of four things: too many zombies alive for the CPU, players defending several separate bases, a base design that makes pathfinding expensive, or a server that has been running all week and is short of memory. Every one of them can be measured from the console and fixed without making the night boring.

This guide explains how the horde is actually built, every setting that changes it, how to read the line the server prints about its own health, and the changes that help most. The wider config file is covered in 7 Days to Die server settings.

How a blood moon horde is built#

Every BloodMoonFrequency days the sky turns red, and at 22:00 game time the horde starts spawning around each player. Three things decide what arrives:

1. How many at once. BloodMoonEnemyCount per player, capped by MaxSpawnedZombies across the server.
2. Which zombies. The game stage. Each player has a game stage that rises with their level and days survived, adjusted by difficulty. Players close together are treated as a party, and the party's game stage - weighted towards the strongest member - picks the spawn groups from gamestages.xml. That is why a level 10 player defending with a level 80 friend sees ferals and radiated zombies they would never meet alone.
3. How fast. ZombieBMMove, the movement speed used during the horde.

As zombies die, more spawn to keep the count topped up, until the night ends at 04:00 or the wave's budget is spent. So the number that matters for the server is not the total killed overnight but the number alive at any moment, and the cost of each one depends on what it is doing.

The cost of an alive zombie is mostly pathfinding. Each one is working out how to reach a player through or around player-built blocks, choosing what to hit, and recalculating every time a block breaks. A zombie walking across open ground is cheap. A zombie inside a maze of half-broken concrete is not.

Every setting that changes horde night#

<property name="BloodMoonFrequency"   value="7"/><property name="BloodMoonRange"       value="0"/><property name="BloodMoonWarning"     value="8"/><property name="BloodMoonEnemyCount"  value="8"/><property name="MaxSpawnedZombies"    value="64"/><property name="ZombieBMMove"         value="3"/>

A few of these interact in ways the comments do not spell out.

DayNightLength is a horde setting in disguise. The horde runs from 22:00 to 04:00, six game hours. At the default 60-minute day that is fifteen real minutes; at 120 minutes it is thirty. Longer days mean a longer stretch of sustained load, which matters more than any peak.

BloodMoonRange makes the night unpredictable, which some groups like. It also makes it impossible to schedule a restart before the horde, which is one of the most useful things you can do. If you use it, keep BloodMoonWarning on so people at least see it coming.

GameDifficulty changes the game stage, and the game stage changes which zombies spawn. Raising difficulty without lowering BloodMoonEnemyCount gives you the same number of zombies, each of them tougher and more often feral or radiated - so they live longer, which means each spends longer pathfinding.

The arithmetic: per player, then capped#

The single most misunderstood thing about horde night is that BloodMoonEnemyCount is not a total.

Two consequences come out of that table. A server that runs well for four players on night 7 can fall over on night 14 because eight people logged in, with no setting changed at all. And raising BloodMoonEnemyCount on a busy server often changes nothing, because the cap is already the limit - which is why players report that "the horde did not get bigger" after an admin raised it.

The cap is also shared with everything else. MaxSpawnedZombies covers the whole server, so zombies wandering around a player who is out in the wilderness during the horde count against the same budget as the ones at the main base. A player who stays out looting on blood moon night is quietly taking zombies away from everyone else's defence.

Raising MaxSpawnedZombies above 64 is possible, and the shipped comment warns that large values will cost server framerate and therefore lag for every client. It is the one number on the server where "more" is reliably worse. If you want a harder night, raise difficulty or speed before you raise the count.

Reading the server's stats line#

You do not have to guess whether the server is struggling. The dedicated server writes a status line to its log at a regular interval, which the panel console shows as it arrives:

Time: 412.37m FPS: 31.52 Heap: 5210.4MB Max: 6012.8MB Chunks: 1844 CGO: 212 Ply: 4 Zom: 32 Ent: 71 (148) Items: 23 CO: 4 RSS: 9120.5MB

The fields have been stable for years but their exact set varies a little between versions. What matters is reading them across the evening. Take a note of the line at 21:00 game time, again at the peak of the horde, and again after 04:00. If FPS drops hard while Zom sits at 32, the server cannot carry 32 zombies around those bases. If FPS holds and players still complain, look at their connections rather than the server - latency, jitter and packet loss is how to tell. If RSS is near your plan's limit before the horde starts, it is a memory problem, not a zombie problem.

The console commands mem and le give the same information on demand. le lists every entity, which is how you find out that the "lag" is two hundred dropped loot bags or a herd of animals stuck in a canyon.

Bases, pathing and why one group lags and another does not#

Two groups with the same settings and the same player count can have completely different horde nights, and the difference is usually the base.

Several bases are several hordes. The horde spawns around players. Four players in four bases is four separate sieges, four sets of chunks loaded, and four pathfinding problems. Four players in one base is one. Asking a group to defend together on horde night is the single biggest performance improvement available, and it costs nothing.

Structural collapses are expensive. When zombies break a support, everything resting on it has to be recalculated, and falling blocks become physics objects for a moment. A tall base on thin supports that collapses in sections creates a burst of work the server feels immediately. Lower, wider, well-supported structures are kinder.

Mazes make zombies think. Zombies pick a route by evaluating block strength along possible paths. A long switchback corridor with many alternative breakable walls gives them more to evaluate every time a block changes. Funnel designs that present one obvious route are cheaper than labyrinths.

Dynamic mesh does work in the background. DynamicMeshEnabled recalculates structural data for player-modified areas. With DynamicMeshLandClaimOnly left at true, that work is limited to claimed areas, which is what you want. Turning it off everywhere saves some CPU; turning LandClaimOnly off makes things worse on an old server.

Loot bags accumulate. Killed zombies drop bags, and a long horde leaves many of them. They count as items and entities until they despawn. It is not usually the main cost, but on a busy night it adds up, and Items in the stats line shows it.

None of this is a reason to tell players how to build. It is a reason to know where to look when one base's defence makes everybody's night stutter.

The settings changes that help most#

In order of how much they help and how little players notice:

1. Restart before the horde. Memory grows across a week on most 7 Days servers. A restart in the afternoon of blood moon day, with a warning, starts the horde with a clean heap. Restart schedules that help covers choosing the hour. With BloodMoonRange at 0 this is easy to schedule, because the horde is always on a multiple of BloodMoonFrequency.
2. Defend together. Not a setting, but worth more than any.
3. Lower `BloodMoonEnemyCount`, not `MaxSpawnedZombies`. For eight players, 6 each is 48 alive rather than 64, spread evenly across bases. Lowering the global cap instead means whichever base spawns first takes the budget.
4. Use speed and difficulty for challenge. ZombieBMMove at 4 with 6 per player is a harder night than 3 with 12 per player, and it is cheaper.
5. Keep `DayNightLength` reasonable. Ninety minutes is a common compromise for evening groups. Very long days stretch horde load across an hour of real time.
6. Check the plan. If FPS falls on a clean, recently restarted server with a modest horde and one base, the CPU share is the limit. The rule in CPU vs RAM for game servers applies: check which resource is at its limit before buying more of the other.

A sensible starting point for different groups:

Scheduling around horde night#

On a server with a fixed blood moon every seven days, the useful automation is simple. Restart a few hours before, save and back up the morning after.

On RE:NODE the Schedules tab takes a cron expression and a list of ordered tasks with delays. A pre-horde schedule might be: a console command say "Restart in 5 minutes for horde night", a five-minute delay, saveworld, a short delay, then a restart power action. A morning-after schedule: saveworld, a delay, then a backup. The panel's Restart sends a clean stop, so the world is written before the process exits, and if a horde ever does push the server to its memory limit it is stopped and restarted clean rather than left swapping - which is better than the alternative, but is still a stop without a save, so the pre-horde restart is the thing to rely on. Cron expressions explained has the syntax.

Matching a schedule to the game calendar takes a little arithmetic. Game days do not line up with real days, so a fixed weekly cron entry will drift relative to blood moons unless the group plays at predictable times. Most groups end up with a daily restart at an hour nobody plays, which covers horde night along with every other night.

Troubleshooting#

Zombies rubber-band and teleport during the horde. The server's FPS has dropped. Check the stats line. Lower the per-player count, get players into one base, restart before the next horde.

The horde is smaller than the setting says. MaxSpawnedZombies is capping it, or players are spread out and the budget is being shared with zombies around someone in the wilderness.

The horde never arrived. BloodMoonFrequency is 0, or BloodMoonRange moved it. gettime shows the current day; count from there.

The server crashed at the peak of the horde. Look at RSS against the plan's limit in the lines before the crash. If it was close, it is memory: restart before hordes and consider the next plan. If memory was fine, read the last lines of the log for a mod error, which is the other common cause.

Horde night is fine but day 1 of a fresh server lags. That is world generation and first exploration, not the horde. See 7 Days to Die world generation.

Lag continues after 04:00. Leftover zombies and loot bags, or a collapse still settling. le shows what is still alive.

FAQ#

Is BloodMoonEnemyCount per player?

Yes. It is the number alive at once for each player, so the total grows with the number of people online. MaxSpawnedZombies caps the total for the whole server.

What is a safe MaxSpawnedZombies value?

Leave it at 64 unless you have measured that the server holds a good simulation rate above it. Raising it is the most reliable way to make horde night lag, and a harder night is better achieved through speed and difficulty.

Why is horde night worse for us than for a friend's server with the same settings?

Base design and spread. Several separate bases mean several sieges, and tall structures that collapse in sections create bursts of physics and pathfinding work. More players than usual online on that night also multiplies the count.

Can I turn blood moons off?

Yes, BloodMoonFrequency set to 0. Wandering hordes still happen. Many groups prefer a longer frequency, such as 14 days, to removing the event entirely.

How do I test the horde without waiting a week?

As an admin, use settime to move the clock to the evening of a blood moon day, play it, and watch the stats line in the console. Restore the clock afterwards, or do the test on a copy of the server.

Does a bigger plan fix horde lag?

Only if the server is actually short of CPU or memory. Read the stats line first. If FPS holds and players still lag, the problem is their connections or the base, and more resources will not change it.