Announcing New Error Reporting and Cache Opt-Out for Data Stores

Hi Creators,

We are excited to announce that you can now view Data Store error messages in real-time on the Error Report Dashboard to debug issues. Additionally, you can opt-out of using the cache in GetAsync to fetch the latest data immediately.

New Error Reporting

Firstly, Data Store errors that occur in your experiences are now reported on the Error Report Dashboard. For each error, a debugging message will be published to the Dashboard in the following format: “DataStoreService: < Error Name >: < Error Message >. API: < API Name >. Data Store: < Data Store name >.”

You can access the Error Report Dashboard by visiting your Creator Dashboard > Creations > Select an experience > Error Report. On the Error Report dashboard, you can view which errors occurred over time, and even filter for specific error names, APIs, and Data Stores with the search feature! For a full list of Data Stores error codes and messages, please refer to the Data Stores Engine guide.

The messages are reported continuously in real-time, so you can get insight into how your experience is using Data Stores even if errors occur when you are offline. We hope this will help you better understand how your experience is interacting with Data Stores, and solve bugs when they show up!

GetAsync Cache Opt-Out

When you use Data Stores, values that you retrieve with GetAsync are stored in the local cache for 4 seconds. By default, GetAsync requests for keys stored in the cache will return the cached value instead of continuing to the backend. Most of the time, this is useful, because GetAsync requests that return a cached value respond faster and do not count towards your server or throughput limits.

However, since GetAsync caches the data for 4 seconds, this can cause issues if you’re trying to keep data perfectly in sync between multiple servers. Previously, you were unable to opt-out of using this cache, meaning that you had no way to get the most up-to-date value except for waiting 4 seconds for the cache to expire. Now, you can opt out by specifying a new DataStoreGetOptions parameter.

Example code:

local DataStoreService = game:GetService("DataStoreService")
local experienceStore = DataStoreService:GetDataStore("PlayerExperience")

-- Create a DataStoreGetOptions instance to specify your desired cache behavior
local getOptions ="DataStoreGetOptions")
getOptions.UseCache = false

local success, currentExperience = pcall(function()
   -- Specify your options as a parameter on GetAsync
   return experienceStore:GetAsync("User_1234", getOptions)

if success then

Note: If you do not specify a DataStoreGetOptions parameter, your GetAsync code will maintain the current behavior, which is to return the cached value if it exists.

Opting out the cache can be useful if you have servers updating shared keys frequently and always need to get the latest value from Roblox servers. However, please note that bypassing the cache may cause you to consume more server and throughput resources since requests that bypass the cache will always count towards your Data Stores server and throughput limits. To minimize your throughput usage, we recommend that you opt out of using the cache only if you have keys that may be updated by multiple servers and you need to get the latest value as soon as possible!

We hope this feature will give you more freedom to create experiences with Data Stores. Please let us know if you have any feedback. We’ll keep improving our services to better serve your needs.

Thank you,
The Roblox Creator Services Team


This topic was automatically opened after 10 minutes.

One thing I noticed with the error reporter is that I only have internal server errors for my Datastores. I am not sure if this is normal, or if it is something I should worry about!


Will users with the edit access for experiences ever be able to view the error dashboard?
Last time I’ve tried it has said that I don’t have permission to access this.


Amazing update, thank you very much :heart:


Thank god. Finally. I have this dumb solution and it sucks. This is so much better. Ty.


The DataStore cache being opt out is such a powerful feature for data handling, we no longer will have to do something hacky such as using UpdateAsync to retrieve latest data!
Error Report makes services such as GA mostly useless too which is a great feature now all we need is custom analytic dashboards and I will no longer have to use cursed alternatives!!!


Be careful when sharing screenshots of the Dev Analytics Dashboard! It’s against ToS.


Those are not analytics, those are just error reports.


My screenshot does not break ToS. It is not metric data, rather, information that can be obtained in game.


Is it possible that datastores could eventually receive a transaction API, where you can update multiple keys in one operation?


This is new? Are these limits per-server or per-experience, if this limit is per-experience it is likely that it will damage my experience that does heavy datastore operations across multiple servers on start-up of each server (each server grabs a 4MB list on start-up).


The cache has never really bothered me since I always use UpdateAsync to interact with DataStores in general; this will continue to be the case even now, as it is just better than SetAsync in every way and I barely have a use case for it.

One question though - why is Roblox inconsistent about how they present methods configurations for us? Some APIs allocate a new datatype class for options while others require you to create a transient instance - the difference between RaycastParams and DataStoreGetOptions, for example. Is there any particular reason why the design called for an instance?

Historically, per-instance. There was a section on the Docs Site about experience-wide limits that I asked about a long time ago but they’re mostly internal and don’t affect developers.


There is a long term plan in mind.

The long term plan is actually neither of these, but rather to take advantage of Luau typing, and take a plain old Lua table but with a well-defined shape specified by a Luau type so you still get code completion / linting.

Unfortunately we’re not quite there yet, and for now APIs are following the closest related thing, which in this case is an Instance since the other DataStore parameters do it that way.


Is there a way to make this dashboard visible to people with Team Create/ in a group


I think we should be able to choose which errors to ignore in some cases so we aren’t overwhelmed by something that’s not necessarily our fault for example Roblox Datastore failing


This is a mix of C# and Lua? What happened?

Anyways this is a neat update. I still don’t know the use of removing the cache, but I don’t make games with complex datastore usage… so


Hi blueberry, thank you for catching this! This is Lua code so the “//” characters should be “–” which is the Lua symbol for a comment. I updated the post with the correction.

I also noticed this C#/Java looking thing:

The variable DataStoreGetOptions is never used, and getOptions is a global variable. I guess it’s not a big deal though! Error reporting for datastores will become useful for me in the future.

1 Like

Ah, I’ve gone ahead and fixed that as well, thanks! I’m happy to hear the Data Stores error reporting will be useful to you, please let us know what you think!

1 Like