Roblox Forum

Quick Summary

• Roblox shipped structured stack traces for server logs on October 23, 2026. Each frame in a server error log now carries a script path, a function name and a line number, and those values are rendered as a link.
• Clicking a frame opens Studio at the exact place version that produced the log and jumps to that script and line. That matters because scripts can change between the error and the investigation.
• The Server Management Service log resource gained a structuredStackTrace field holding parsed JSON per frame: Line, FunctionName, ScriptPath, ScriptUniqueId and IsDynamic.
• Two documented gaps: Roblox-generated errors carry no trace data, and frames where IsDynamic is true have no stable reference to a script in Studio, most often because a script was cloned at runtime.
• This is a Creator Hub and Open Cloud change, not a player-facing feature. If you only play Roblox, nothing in your client changes.

What changed on October 23
Roblox posted the announcement in its Updates and Announcements section on October 23, 2026, written by a Roblox Staff member and tagged creator-hub. Within roughly four hours it had pulled about 800 views and around 55 likes, with a handful of replies.

The change is narrow. Server error logs in Creator Hub now resolve their stack frames. Before this, a log entry gave you a script path, a function name and a line number as plain text, and finding the file was your job. Now those three values are a hyperlink, and clicking it opens Studio to the specific place version and directly to the target script and line.

The place version detail is what makes this more than a convenience. By the time you open a log, the live scripts may have moved on. An error from an hour ago can point at a line that no longer means anything if the script was edited since. Roblox states the link opens the place version where the error occurred, so the line number you land on is the line that actually failed.

The structuredStackTrace field
The same change landed on the API side. The Server Management Service now includes a structuredStackTrace field on the log resource, and it holds parsed JSON metadata for each frame instead of a blob of text you would have to parse yourself.

Each frame carries five values:

Field	Type	What it holds
Line	int	The line number in the script
FunctionName	string	The function the frame was executing
ScriptPath	string	Path to the script
ScriptUniqueId	string	Identifier for the script instance
IsDynamic	bool	Whether the frame has a stable Studio reference

One caveat on that table. Roblox lists the field names and their types, but the announcement does not describe what each field means, so the third column is my reading of the names rather than a quote from the page. Treat it as interpretation.

How to read a log now

1. Open Creator Hub and find the game server log you are chasing. The error entry shows the script path, function name and line number as a link.
2. Click the link. Studio opens at the place version that produced the log, on the script and line that failed.
3. If the link is not clickable, check whether the frame is marked IsDynamic. Those frames have no stable reference to a script in Studio, most often because a script was cloned at runtime.
4. If there is no trace at all, the error is likely one Roblox generated itself rather than your code. Roblox says certain Roblox-generated errors are missing stack trace data because they are not connected to creator code.
5. For your own tooling, pull the structuredStackTrace field from the log resource instead of parsing the rendered text, so your pipeline keeps working if the display format changes.

The log endpoint this sits behind
The announcement points at the game server log retrieval endpoint in the Open Cloud observability reference. The operation is a GET against /server-management/v1/universes/{universeId}/places/{placeId}/versions/{versionNumber}/game-servers/{jobId}/logs, and it lists game server logs for a specific server job id.

The same reference page documents listing active game servers for a place version, retrieving the available filter options, and the restart operations: forecasting a restart, launching it, and monitoring its status. Every endpoint on that page is marked Beta.

That Beta label is worth keeping in mind. The field names above are the current shape of the API, not a frozen contract, so pin your tooling to the field names and expect the surrounding surface to keep moving.

What this does not fix
The announcement is about server logs. It does not extend to client-side errors, and that gap is exactly what one of the first replies asked about, requesting game-wide error logs, server and client, through the Open Cloud API the way the Error logs section in Creator Hub exposes them.

Two other limits are documented rather than requested. Roblox-generated errors can carry no trace at all, since they are not connected to creator code, and frames marked IsDynamic have no stable Studio reference, which happens most often when a script is cloned at runtime. If you see a trace you think should exist, Roblox asks that you report it so they can investigate.

What the community asked for in the first hours
The thread was small, but three asks came up clearly and they are worth knowing about if you plan to build on this:

• A copy button. One programmer pointed out there was no quick way to copy a stack trace without manually highlighting the text, and asked for a copy-to-clipboard button so traces could be pasted into tickets.
• Better coroutine attribution. Another asked for accurate traceback into coroutine.wrap, saying the error message always points at the line calling coroutine.wrap rather than the line inside it that actually failed, and that they keep a bool to avoid coroutine.wrap just so they can see which line errors.
• Open Cloud error log access. A third asked whether game-wide error logs, server and client, could be reached through the Open Cloud API the way the Error logs section in Creator Hub exposes them.

Roblox has not answered any of those three in the thread. Treat them as open requests rather than committed work.

FAQ

Does this change anything for players?
No. This is a Creator Hub and Open Cloud change to how server error logs are displayed and exposed. Nothing in the Roblox client changes.

Do I have to enable anything?
The announcement does not mention a toggle. Stack traces appear on server error logs in Creator Hub, and the structuredStackTrace field is present on the log resource.

Why is one of my stack frames not clickable?
Frames where IsDynamic is true have no stable reference to a script in Studio. Roblox says this most often happens when a script is cloned at runtime, though it can occur for other reasons.

Why does an error have no stack trace at all?
Certain Roblox-generated errors are missing stack trace data because they are not connected to creator code. Roblox asks that you report errors you believe should carry a trace.

Does this cover client-side errors too?
Not according to the announcement, which is written around server logs and game server error logs. The request to expose client-side errors through Open Cloud is still open in the thread.

Can I use this in my own tooling?
Yes. The structuredStackTrace field on the log resource holds parsed JSON per frame, so you can build on the error data directly. The announcement links the observability reference for the log endpoint.

Is the observability surface stable?
No. The announcement describes the launch of structured stack traces and the new field, but the underlying observability endpoints are documented as Beta, so the shape can change.

Sources

• Roblox Developer Forum: Announcing Studio Deep Links on Stack Traces for Server Logs - the announcement itself, posted October 23, 2026, with the field spec and both FAQs
• Roblox Creator Hub: Observability - the Open Cloud server log retrieval endpoint and the Beta status of the surface
• Roblox Developer Forum: Weekly Recap October 19-23 2026 - dated anchor confirming the feature landed during that week