Roblox Teleportservice

Getting Players Between Places Without the Usual Headaches

TeleportService is the built-in Roblox API for moving players from one place to another. It sounds straightforward, but anyone who has tried to use it at scale knows there are enough gotchas to make you want to throw your keyboard out the window. The core functions are Teleport, TeleportAsync, and TeleportToPlaceInstance. They do roughly the same thing but behave differently under load. Teleport takes a place ID and a player or group of players, then routes them to the destination. The catch is that it requires a server-bound execution context. You can't call it from a local script, and if you try to run it from a client, Roblox will silently ignore the call or throw an error that means nothing to someone who doesn't know what to look for. Put the call in a server script, preferably in ServerScriptService or a dedicated module that runs on the server, and it will actually attempt the transfer. TeleportAsync is the batch version. You pass it an array of players and a table of options, and it handles them in a structured way. The return value is a table with results for each player, which tells you whether the teleport succeeded, failed, or is still in progress. This matters because at scale, individual teleport calls can overwhelm the gateway if you fire them all at once. TeleportAsync gives you a bit more control over what happens when things go wrong.

TeleportToPlaceInstance is different. Instead of just giving it a place ID, you pass it a specific instance ID of a running game. This means you're sending players to an exact server that already exists, rather than asking Roblox to find or create one. It's useful for private servers, matching systems, or when you need players in the same room for a lobby experience. I ran into a specific problem a while back where I was teleporting about two hundred players from a central hub into game instances using TeleportAsync. Half of them arrived, the other half just sat there loading forever. The error messages said nothing useful. What was actually happening is that the destination servers were hitting the concurrency cap for that place. Roblox limits how many players a single server instance can accept during a teleport burst, and once you cross it, the extra teleports queue up or fail silently depending on your options. The workaround was to add a delay between batches and use TeleportService:GetActiveServerPlayerCount to check load before firing the next wave. It added maybe thirty seconds to the overall process but stopped the whole thing from breaking.

Common Pitfalls That Nobody Talks About

The first thing most people get wrong is assuming that passing ExtraData through a teleport preserves it automatically. It doesn't. You have to explicitly set it in the teleport options table, and then on the destination side, you have to retrieve it from the Player instance using the properties that TeleportService exposes. If you skip this step, your data just disappears and you spend an hour wondering why your matchmaking scores aren't showing up. Another thing is the cooldown. After a player teleports, they can't immediately teleport again without waiting through a short cooldown window. This is by design to prevent abuse, but it trips up developers who try to chain teleports in quick succession, like moving a player from a lobby to a minigame and then to a results screen. I've seen people work around it by having the destination place send the player back to a transit hub instead of chaining direct teleports. It adds a hop but keeps everything flowing. Also worth noting: TeleportService does not guarantee delivery. If the destination server crashes or is full, the teleport can fail, and if you're not checking the return values, you won't know it happened until players complain. Always wrap your teleport calls in pcall and handle the failure cases explicitly. Log the error codes. Roblox provides them, but they're not intuitive if you've never looked them up.

When Teleportservice Falls Apart

The biggest limitation is that all of this is server-authoritative. You can't make a player teleport from the client without the server approving it. Some people try to route this through remote events, which works but adds latency and an attack surface. If a malicious client fires a remote that triggers a teleport to an exploit-friendly place, you're responsible. Validate everything before you call Teleport. There's also no built-in cross-game persistence. TeleportService moves players between places in the same universe by default. If you want to teleport to a completely different game outside your universe, you need to use the cross-game teleport variants, and those require your game to be in good standing with Roblox. I've had games rejected for cross-game teleports because the developer hadn't completed the necessary verification steps, and it took weeks to sort out. If you're building something that depends on moving players across multiple standalone games, plan for that friction early. For most use cases, TeleportService is fine. It's not elegant, it's not forgiving, and it will bite you if you treat it like a simple function call. But it's the standard tool for the job, and knowing where it breaks is what separates people who ship experiences from people who spend three weeks debugging a teleport loop.