Fix Minecraft "Can't keep up" TPS Lag on GlassHosting
What the message means
When the console prints that the server is behind or "Can't keep up," one tick took too long. TPS (ticks per second) droops below 20 and players feel rubber-banding. On GlassHosting this is usually entities, chunk gen, redstone, or undersized RAM/CPU—not your friends' Wi‑Fi.
Triage order
- Check panel CPU and RAM graphs during the lag.
- Scan console for plugin errors looping every tick.
- Lower view/simulation distance temporarily.
- Ask players to pause heavy farms; visit farms in spectator to inspect.
- Remove recently added plugins/mods one by one.
- Pre-generate terrain if exploration spikes MSPT.
- Upgrade plan resources if you are honestly undersized.
False friends
A single player's poor upload does not print "Can't keep up" on the server. That message is server-side. Client FPS issues are separate—have them lower render distance locally while you fix TPS.
After major world edits, run a calm period with fewer players to let chunk saves settle. Schedule restarts during low population if memory slowly climbs from a leaky plugin, and update that plugin.
When to ticket
If graphs show CPU pegged after you trimmed farms and plugins, GlassHosting support can help you evaluate a larger plan. Paste timings summaries and the approximate player count—avoid sending private keys or unrelated system logs.
Measure before you guess
Open the resource graphs on panel.glasshosting.com during a normal play window and during a busy one. Write down approximate CPU and memory percentages alongside how the game felt. That habit turns vague “it lags” reports into actionable upgrades or config tweaks.
If graphs look calm while players stutter, ask whether the issue is client FPS, wifi, or a single loaded farm chunk. If graphs are pegged, stop adding content packs until you either tune view distance/entities or upgrade the GlassHosting plan from the client area.
When to involve GlassHosting support
Open a ticket from billing.glasshosting.com when the platform itself looks wrong: panel cannot start the process, allocations seem missing, or multiple unrelated networks cannot reach the service. Include service name, timestamps, and console excerpts without secrets.
For game-logic questions (plugin conflicts, datapack design), include what you already tried. Skim related knowledgebase articles first—many “outages” are EULA flags, edition mismatches, or whitelist misses.
Backup discipline (repeat until boring)
Create a named backup before every risky change: version upgrades, mod installs, permission overhauls, or world-edit events. Download a copy of irreplaceable worlds over SFTP to your PC at least occasionally so you are not relying on a single storage location. After a restore, verify spawn, inventories, and plugin folders before declaring victory in Discord.
GlassHosting makes backups accessible in the panel—use them. A backup you never tested is only a hopeful file. Once per season, restore to confirm the process while the stakes are low.
Beginner pitfalls we see constantly
- Skipping the EULA or auth step and assuming the host is broken
- Installing dozens of plugins before the first successful join
- Sharing the wrong edition address (Java vs Bedrock)
- Editing files while the server is still writing them
- Reinstalling as a first step instead of reading the console
Slow down, read the console, backup first, and change one variable at a time. That pattern alone prevents most first-week disasters on GlassHosting.
Documentation habit
Keep a one-page note with: panel URL, who is lead admin, current game version, last backup name, and the exact join string. When you hand off admin duties, that note prevents accidental reinstalls and wrong-version clients.
Quality bar
Definition of done for any change: server starts clean, two players join, critical plugins load, and a fresh backup exists. If any checkbox fails, roll back before opening the gates wider.
Related links: panel.glasshosting.com · billing.glasshosting.com · glasshosting.com.
