Rubberbanding
Rubberbanding is when something in an online game, such as a character, a vehicle, an object or a projectile, snaps back or jumps to a new position, as if pulled by a rubber band. It happens when what a player’s screen showed and what the game server decided drift apart, and the correction is large enough to see. The drift can come from a player’s own predicted actions, from late updates about other players and objects, or from a server falling behind its own schedule.
Also called
rubber banding, rubber band lag
,
What Happens When a Player Rubberbands?
In many online games, the player’s own client does not wait for the server. When a key is pressed, the client moves the character at once, and the server confirms that movement a round trip later. Most of the time the two agree and nothing shows. When the server decided something the client did not know about, such as a knockback, a blocked path or a lost input, the client’s character has already run ahead on the wrong path. The server’s answer pulls it back to where the server says it is, and that pull is the rubber band. The same goes for anything the client predicts: a vehicle, a thrown object, a projectile.
This is the loop many netcodes use for the local player: predict, then rewind to the server’s state and replay the inputs since, a form of rollback. Games that wait for confirmation instead, such as delay-based or lockstep games, rarely rubberband. They show input lag or a stall instead.
Players use the word for three different snaps, and each points to a different part of the game:
Your own character snaps back. The server corrected the client’s prediction of your movement.
Other players and objects jump or warp. Updates about them arrived late, the client drew or guessed where they were going, and corrected when the real update landed. By default, Valve’s Source engine stops guessing after 0.25 seconds of missing updates, because prediction errors grow too large beyond that (Valve Developer Community). Interpolation covers how remote players are drawn.
Everyone in the match stutters at once. The server fell behind its own tick, so every player’s correction arrives late and together.
Telling them apart is the first step, because a fix for one often does little for the others.
In Practices - Insights from Edgegap's Blog
Article's key insights
Desync is a disagreement, not a delay: Lag means information arrives late. Desync means two machines hold different versions of the same world, which is a separate failure with separate fixes.
There are two distinct kinds: Replication desync, where an authoritative server corrects a client that guessed wrong, and determinism desync, where peer simulations diverge and the session stops outright.
Rubberbanding has two levers: How often the client mispredicts, which latency drives, and how visible each correction is, which netcode drives. Pull either one and players see less of it.
Tick rate is neither lever: Raising it does not make predictions more accurate, and on a connection already dropping packets it makes the artifacts worse.
"A desync has occurred" is a checksum failing: Lockstep games compare state hashes every turn, so one divergent float or one unsynchronized random call ends the session.
Why Do Players Rubberband With a Low Ping?
A short round trip keeps the band short, so players with a good connection expect not to see it. When they still do, the cause is often one of three things that have little to do with their connection.
The server misses its tick. Each tick is a fixed time budget for the whole match. When the work does not fit, for example many players or objects in one place, a burst of physics, or a long pause in the server process, the server falls behind. As Edgegap’s netcode fundamentals guide puts it, “Players see rubberbanding, teleporting and rejected hits.” Because the delay sits on the server, every player in that match feels it at the same moment.
A movement check rejects the move. Many servers check each move against what the rules allow. Unreal Engine’s character movement can detect a client whose clock runs ahead of the server, a speed hack signature, and force corrections once the gap passes an allowed drift (Epic documentation). An honest player whose client hitches or drifts can trip the same check.
The client and the server run different movement code. If a speed boost, a slope or a collision is applied on the server but not predicted on the client, or the reverse, the client guesses wrong every time it happens. The tell is a snap that repeats at the same spot or with the same ability, at any ping.
Latency decides how far a wrong guess can travel. These three decide whether the guess is wrong in the first place.
How Much Error Should a Server Accept Before Correcting?
Correcting every tiny difference would make movement jitter constantly, so many netcodes let small errors through. In Unreal Engine, MAXPOSITIONERRORSQUARED sets “the max position error that is accepted (not corrected)”, and an optional setting lets the server take the client’s position when it falls within that error (Epic documentation).
Once a correction is needed, the next choice is how it looks. Valve’s Source engine notes that a hard correction “may cause the client’s view to jump erratically”, so by default it spreads the correction over a short time instead (Valve Developer Community). Unity’s Netcode for Entities leaves the choice to the developer, who registers a smoothing action per component (Unity documentation). Smoothing makes a snap less jarring, but it briefly shows a position that is wrong, as client-side prediction covers.
The tolerance is a trade-off. A wider one means fewer visible snaps and more trust in the client, which also leaves more room for a modified client to move further or faster than the rules allow. A tighter one keeps the server in charge and shows more corrections. Many games settle the balance per movement type, looser for ordinary running and tighter for dashes or teleports, and leave the rest to anti-cheat and an authoritative server.
How Do You Find the Cause of Rubberbanding?
A player report says “rubberbanding” whichever of the three snaps it was. The server knows more. If it logs each correction it sends, with the player, the distance, the reason (prediction miss, rejected move, or late tick), the player’s round trip and the server’s frame time at that moment, the pattern usually points to one cause:
Pattern in the corrections | Likely cause |
|---|---|
Every player in one match, at the same moment | The server missed its tick budget |
A few players, with long round trips or packet loss | Distance and connection |
The same spot or ability, at any ping | Client and server movement code differ |
Repeated rejected moves for one player | Clock drift, or a cheat |
On Edgegap, each deployment shows container metrics for processor, memory and networking, in one-minute averages on the free tier and one-second intervals on Pay as You Go (Edgegap docs), so a late tick can be compared with that match’s resource use, to see whether the server code needs profiling or the match needs more headroom. For the distance share, each match’s server is placed from its players’ IPs or ping beacon results, and in independent replays of one studio’s live traffic, dedicated server placement measured a 58% average round-trip time reduction against public-cloud relay placement (platform data, 30 September 2026). A shorter trip shortens the bands that come from distance; a missed tick or mismatched movement code still needs its own fix.
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Test Movement on Dedicated Servers, From Where Your Players Are, and Keep Monitoring It
Rubberbanding often hides during development. On a local build or a host’s own machine, the client is barely ahead of the server, so corrections stay too small to see, and movement can ship without anyone on the team seeing it snap.
Test the way players will connect: the dedicated server build, under real match load, over a real network path. Run playtests from outside the region where the team works, with testers or servers far enough apart to give the round trips a share of your players will have. Engine tools such as Unreal’s network emulation and Unity’s Network Simulator cover the days in between.
Then keep it running after launch. A weekly look at corrections per player-minute, split by location and by cause, shows when a patch, a new map or a busier mode made the band longer, before players start reporting it.
On Edgegap, once the server build is uploaded, a playtest server can be deployed from a single API call close to each group of testers, where capacity is available, with container metrics for each deployment, so the same check can run across the locations you launch in.
Jakub Motyl, Product Director
,
