Open Cloud Instances API: root:listChildren returns 500 “Exception was thrown by handler” for 80+ hours (multiple universes)
Summary
Since 2026-07-16 03:54 UTC, every authenticated call to the Open Cloud v2
Instances endpoint …/instances/root:listChildren has returned HTTP 500 with
body {"code":2,"message":"Exception was thrown by handler.","details":[]}.
The failure is isolated to the Instances handler:
GET /cloud/v2/universes/{universeId}returns 200 for the same API key, in
the same request batch, for both affected universes.…/instances/root:listChildrenreturns 500 for all three places tested,
across two independent universes.
So the key authenticates, the universes resolve, and the request reaches the
service — the fault is post-auth and specific to the Instances handler. This is
not a key-scope, content, or lint problem on our side.
Duration at time of writing: ~82 hours, continuous.
Reproduction
Single authenticated GET, x-api-key header only:
GET https://apis.roblox.com/cloud/v2/universes/{universeId}/places/{placeId}/instances/root:listChildren
Header: x-api-key: <Open Cloud API key with instances read scope>
Control (works — proves the key and universe are fine)
GET https://apis.roblox.com/cloud/v2/universes/{universeId}
→ 200, full universe body
Affected resources
| Env | Universe ID | Place ID | universe GET | root:listChildren |
|---|---|---|---|---|
| dev | 6929140041 | 89363467031021 | 200 | 500 |
| ppe | 6929140041 | 96241449538567 | 200 | 500 |
| prod | 10146199208 | 137231663982838 | 200 | 500 |
Two distinct universes (6929140041, 10146199208) under the same account both
fail, which rules out a per-universe data problem.
Exact response body
{"code":2,"message":"Exception was thrown by handler.","details":[]}
Identical across all three places and every attempt over the 70-hour window.
Timeline (UTC)
| When | Event |
|---|---|
| 2026-07-15 13:50 | Last successful deploy. Everything healthy. |
| 2026-07-16 03:54 | First observed 500. Failures continuous from here. |
| 2026-07-18 08:00 | Deploy attempt fails |
| 2026-07-18 10:24 | Read-only probe confirms Instances-specific fault |
| 2026-07-18 11:55 | Read-only probe re-confirms |
| 2026-07-18 14:00 – 21:03 | Three more deploy attempts fail |
| 2026-07-19 02:04 | Read-only probe — still 500 on all three places, universe GET still 200 |
| 2026-07-19 14:20 | Read-only probe — still 500 (dev + prod re-confirmed), universe GET still 200 |
Every listed probe re-runs the real authenticated request against the live
service; none of these are synthetic or cached results.
What we ruled out
- API key / auth — a 500 is post-auth, and the universe-metadata GET returns
200 with the same key in the same batch. - Key scope — same key, same batch, one endpoint family works and the other
does not. - A single bad universe or place — two independent universes and three places
all fail identically. - Our request shape — unchanged since the last successful run on 2026-07-15,
and the control GET against the same base URL succeeds. - A transient blip — 82 hours, continuous, across many independent attempts.
Impact
Our entire script-deploy path is frozen. Roughly ten scripts across fifteen
commits have been undeployable since 2026-07-15 13:50, and every downstream
task that depends on a deploy is blocked behind this.
What would help
- Confirmation that the Instances handler fault is known and being tracked.
- Any workaround for script deployment that does not route through
instances:listChildren. - An ETA, or a signal to watch, so we can stop polling blind.