Introducing UnreliableRemoteEvents

Hi Creators!

We are excited to announce the release of UnreliableRemoteEvents! This is available immediately and adds a new creatable instance, UnreliableRemoteEvent, that sends the event unreliably and unordered through the network. This is in contrast to RemoteEvents which are sent reliably and ordered.

UnreliableRemoteEvents are useful for implementing ephemeral events. Examples include particle effects, sound bites, and events that impact visuals but are not crucial for game state.


This new instance shares the same methods, events, and properties as RemoteEvents but with a different network guarantee.

That is, you can:

  • Create them in a script by calling “‘UnreliableRemoteEvent)” and connect to them like you would with RemoteEvents. Here is a simple script example:
local unreliableEvent ="UnreliableRemoteEvent")
unreliableEvent.Name = "UnreliableEvent"
unreliableEvent.Parent = workspace

while true do
local unreliableEvent = workspace:WaitForChild("UnreliableEvent")

local function onClientMsgEvent()
	print('Received UnreliableRemoteEvent from Server!')


There are a couple of things to keep in mind when using UnreliableRemoteEvents:

  1. There is no ordering guarantee between UnreliableRemoteEvents and anything else. UnreliableRemoteEvents may be processed in a different order than they were sent.

  2. UnreliableRemoteEvents may be dropped to prioritize bandwidth or CPU usage in addition to any loss that occurs over the network.

Known Issues

  1. UnreliableRemoteEvent payloads should be at most 900 bytes. Events with a larger payload will be dropped. When this happens in RobloxStudio, we will output a log message in the output menu indicating how many bytes the event has gone over. Unfortunately, this will require trial and error, but we are working to give you better tooling in the future in addition to increasing the bytes limit.

  2. UnreliableRemoteEvents are not currently prioritized over other traffic. This means delivery can be affected by other networked messages in your game, both reliable and unreliable. While we’ve already implemented several methods to decrease the impact, we’re looking into further improvements for this scenario.

We want to hear from you!

We know this has been a frequently requested feature and we’re excited to work with you to improve it continuously. To help steer us in the right direction we’d love to hear your feedback, questions, and any issues you encounter.

Thank you!


This topic was automatically opened after 10 minutes.

Huge release for competitive experiences on Roblox! Can’t wait to see how this is implemented by developers.


Ladies and gentlemen, after years of wait, it finally happened


Outstanding feature that many of us have been waiting a very long time for. Massive thank you to all involved.

I do notice though that there’s no mention of a reliable unordered remote. Personally, I think that they’d be a great fit alongside unreliable remote events, given that a developer could put everything that’s not timing-sensitive (but may congest network channels nonetheless, custom terrain replication as an example) behind one of them. Might be a very easy gain in terms of latency for some games. Would love to hear an engineer’s thoughts on implementing more types of remotes (such as reliable unordered) in the future!


Glad it’s finally out!

I and others have been anticipating this update for a while, and I can’t wait to use this to optimize certain systems like movement and many others. By immediately, do you mean that there is no beta stage for this?



Do unreliable remote events have to wait for the current reliable remote events on the incoming side to clear before they are handled?


Amazing update, I can definitely see this being used for mass-sending data like in replication or other things that developers want to send often but don’t really need reliable or ordered.

Its like Roblox’s engine that uses reliable packets for chat and unreliable for movement.

This is a great update! Tysm Roblox :slight_smile:


This is great! Lets just hope this dosen’t backfire… By the way, is :FireServer() also on this? I’m confused.


This is amazing! With this use case I could utilize this for small things such as sound effects, or even visual things! Basically nice if it works, but not important type of stuff!


I understand why it’s called that, but I imagine to someone not really in dev circles it must sound pretty strange :stuck_out_tongue:

Great new feature!


This and the buffer type are going to be huge for performance gains. Appreciate this finally coming out!


very useful for my rollback netcode! much appreciated!


I have been eagerly waiting for this beta to release. I heard that these were being added and developed an entire system that uses these to function and now i can finally swap out the remotes and fully test it out.

Huge thanks to the team working on this!


Oh yeah, one thing to note though. Because its a completely new instance it might confuse some beginners that are learning Roblox scripting and it would maybe better if you people at Roblox would just have put a property like IsReliable or Reliable on the normal RemoteEvent instead. This would also allow us to set if one request should be reliable or not dynamically.

Either way, great update.


This is incredible work, we’ve been waiting long on this! :raised_hands:

I can expect especially Chickynoid to benefit greatly from this (server authoritative characters)


FINALLY DUDE OH MY GOD this is absolutely required for networking


This wouldnt really work because theres not a set amount of variables you can send through a remote, and the only possible solution would break every game (make the first variable if it is reliable, impossible to change without breaking absolutely everything). Im no networking engineer but i can guess that their backends are vastly different to where this is very infeasable and impractical.


They’re similar to remote events, not bindable events. You need to use OnClientEvent/OnServerEvent.


Nice job on this one. I am really excited to mess around with these.