Lag, memory, and the resource cap

Two different bottlenecks

Node contention and guest overload look similar from inside a game. Node contention is the host or its network struggling across instances. Guest overload is your server asking for more memory or CPU than the size allows, usually because of mods, view distance, world size, or player count.

The panel reports observed power and jobs, not a live performance graph. Console is the first place to look for an out-of-memory kill, a watchdog crash, or a tick loop that is falling behind.

Common guest causes

A Java heap set larger than the instance memory invites an out-of-memory kill. A view distance that is too high for the player count keeps more chunks loaded than the CPU can tick. A large modpack adds startup and per-tick cost before anyone joins. A world that has never been trimmed carries every chunk players have visited.

Plugin or mod errors can also present as lag: a broken event handler, a database call on the main thread, or a repeating task that never yields. Read the console before changing the size.

1. Read Console for out-of-memory, watchdog, or exception lines.
2. Lower view and simulation distance and restart from the header.
3. Remove or update the mod or plugin named in the first error.
4. Compare the pack author’s memory guidance with the size you bought.
5. If the guest is within its cap and the node still looks unwell, open Support with the instance id and timestamps.

What Foxcore does not do

The panel does not auto-scale an instance, add burst memory, or silently move you to a larger size. There is no restart button in this wave; stop and start from the header if you need a fresh process.

If the cap is genuinely too small, the fix is a larger purchase or a lighter pack, not a hidden setting. Support can confirm what the instance is reporting, but staff do not start guests from the Worker.