Infinite Yield Possible on WaitForChild

“Infinite yield possible” means WaitForChild has waited more than 5 seconds for a child that hasn’t appeared, and it will carry on waiting. The usual causes are a wrong name or parent, an object that never gets created or never reaches the client, or StreamingEnabled. To fix it, correct the path, or use a timeout with a nil check, or use FindFirstChild where the object should already exist.

What the warning actually means

The message names the parent and the child it’s waiting for:

Infinite yield possible on 'Workspace:WaitForChild("Part")'

It’s a warning, not an error. According to the Roblox documentation for Instance:WaitForChild, if you don’t pass a timeout and the child doesn’t exist after 5 seconds, a warning prints saying the thread may yield indefinitely. The call keeps waiting. It doesn’t give up and it doesn’t return nil. Some tutorials claim otherwise, but without a timeout argument WaitForChild returns only once the child exists.

That’s why features “just break”: every line after the waiting call is paused. The GUI never opens, the tool never equips and the remote is never connected, and the only clue is a yellow line in the Output window. If you’re new to reading Output, see how to read Roblox script errors in the Output window.

Step 1: Read the path and check the name and parent

Read the full path in the warning: the part before :WaitForChild is the parent, and the quoted string is the child’s name. Then press Play (not Edit mode) and look in Explorer for that object under that exact parent. Use the Client/Server toggle on the Home tab to check each side separately, because they can differ.

Common slips:

Capitalisation: "door" and "Door" are different names.
A trailing space in the object’s name.
The object was renamed, but the script wasn’t updated.
Waiting on workspace when the object sits inside a Model or Folder.

If the object lives inside a folder, wait on each level of the path:

local door = workspace:WaitForChild("Map"):WaitForChild("Door")

Step 2: Check where the object is created and who can see it

Created by a LocalScript? It exists only on that player’s client. A server Script waiting for it will wait forever.
Created by the server? It replicates to clients, but the documentation notes that replication order and timing aren’t guaranteed. That’s exactly why client code uses WaitForChild rather than assuming the object is there.
In ServerStorage or ServerScriptService? Those containers never replicate to clients, so a LocalScript waiting on anything inside them will always trigger the warning. Put objects both sides need in ReplicatedStorage.

The fix is to create the object on the side that needs it, or move it to a container that side can see.

-- LocalScript: this will never resolve, because ServerStorage doesn't replicate
local ServerStorage = game:GetService("ServerStorage")
local template = ServerStorage:WaitForChild("SwordTemplate")
-- Fix: move SwordTemplate to ReplicatedStorage
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local template = ReplicatedStorage:WaitForChild("SwordTemplate")

Step 3: StreamingEnabled (works in Studio, breaks live)

With instance streaming on, BaseParts and models far from the player may not be on the client yet. The documentation lists this as one reason a child might not be there. A LocalScript that blocks on a distant part will warn and stall until the player gets close enough, which may be never.

Fixes, in order of preference:

React when the object streams in, rather than blocking. Listen with ChildAdded/DescendantAdded, or tag the objects and use CollectionService:

local CollectionService = game:GetService("CollectionService")
local function setupDoor(door)
	-- runs for each tagged door that is (or becomes) present on this client
	print("Door ready:", door:GetFullName())
end
for _, door in CollectionService:GetTagged("Door") do
	setupDoor(door)
end
CollectionService:GetInstanceAddedSignal("Door"):Connect(setupDoor)

For models that must always be present, set Model.ModelStreamingMode to Persistent, or to Atomic so the whole model arrives at once. See the ModelStreamingMode reference.
For non-essential objects, use a timeout with a nil check (Step 4).

Switching StreamingEnabled off isn’t the fix. Streaming exists to keep memory and load times down, so turning it off trades one problem for another. Handle streamed objects in your code instead.

Step 4: Use a timeout and handle nil, for non-critical code

Pass a number of seconds as the second argument. If the child hasn’t appeared by then, WaitForChild returns nil instead of waiting forever, and no infinite yield warning is printed:

local door = workspace:WaitForChild("Door", 10)
if not door then
	warn("Door not found after 10 seconds")
	return
end
door.Transparency = 0.5

The nil check is the important part. A timeout on its own just moves the failure to the next line, as “attempt to index nil with 'Transparency'”. Don’t put timeouts on objects your script truly can’t run without. Fix the path or the replication instead.

Step 5: Use FindFirstChild where the object should already exist

The documentation describes FindFirstChild as the more efficient choice for objects you assume already exist. It returns the child or nil straight away, without yielding. Roblox’s own streaming guidance recommends FindFirstChild with a nil guard on startup-critical paths, rather than a blocking wait.

local Players = game:GetService("Players")
local playerGui = Players.LocalPlayer:WaitForChild("PlayerGui")
local hud = playerGui:FindFirstChild("HUD")
if hud then
	hud.Enabled = true
end

Step 6: Stop calling WaitForChild inside events

Resolve references once at the top of the script and reuse them. Calling WaitForChild inside a frequently firing event means every firing can stall, and a missing object produces a fresh warning each time.

-- Before: waits inside every Touched event
script.Parent.Touched:Connect(function(hit)
	local sound = workspace:WaitForChild("Sounds"):WaitForChild("Pickup")
	sound:Play()
end)
-- After: resolve once, reuse
local pickupSound = workspace:WaitForChild("Sounds"):WaitForChild("Pickup")
script.Parent.Touched:Connect(function(hit)
	pickupSound:Play()
end)

Common versions of this warning and what each usually means

Warning mentions	Usual cause
`PlayerGui:WaitForChild("ScreenGui")`	The GUI isn’t in StarterGui, has a different name, or `ResetOnSpawn` recreated it after respawn.
`Character:WaitForChild("Humanoid")` or a body part	A custom character lacks that part, or it has a different name (for example R6 and R15 part names differ).
`ReplicatedStorage:WaitForChild("RemoteEvent")`	The server script that creates the remote errored, or the remote lives in ServerStorage. See RemoteEvent not firing.
`Workspace:WaitForChild("Part")` on the client	Usually streaming (Step 3).
CoreGui objects (for example TopBarApp)	Roblox’s own interface. According to DevForum reports these usually don’t come from your scripts. That isn’t confirmed in the official docs.

If the waiting happens inside a required module, see ModuleScript not working. For leaderstats values, see leaderstats not updating.

Quick checklist

Read the parent and child name in the warning.
Check the object exists under that parent in Play mode, on the right side (client or server).
Fix capitalisation, spaces and renamed objects.
Wait on each folder or model level in the path.
Move objects the client needs out of ServerStorage and ServerScriptService into ReplicatedStorage.
With StreamingEnabled, react to objects streaming in, or set ModelStreamingMode on models that must be present.
Use a timeout plus a nil check for non-essential objects, and FindFirstChild where the object should already exist.
Resolve references once, not inside events.

Still stuck? Let Stellar check it

Debug it free. Paste the full Output warning, the script, its type (Script, LocalScript or ModuleScript), where it lives in Explorer and what should happen into Stellar AI, or start from the Roblox Lua error fixer. The free plan includes up to 15 Stellar Fast replies a day, with no card required.

Let it look at your place. The Roblox Studio agent can inspect the open place read-only and propose a plan. Edits happen only after you approve them, and they can be undone. Check plans for availability.

Have it handled. The £99 Priority Script Fix covers one focused Roblox Luau problem. You get corrected code or guidance plus test notes, and you send the details through a private intake page after checkout. Test any fix in Studio before you publish.

FAQ

What does “Infinite yield possible on WaitForChild” mean in Roblox?

WaitForChild has waited more than 5 seconds for a child that hasn’t appeared under the named parent. It keeps waiting, so the code after it doesn’t run.

Is “Infinite yield possible” an error or a warning? Does it stop my script?

It’s a warning, not an error. It doesn’t stop the whole script, but the thread that called WaitForChild stays paused until the child appears, so everything after that line waits too.

Does WaitForChild return nil after 5 seconds?

No. Without a timeout, it only prints the warning at 5 seconds and keeps waiting. It returns nil only when you pass a timeout argument and the time runs out.

Why does it only happen in a live game and not in Studio?

Usually because of StreamingEnabled or replication timing. In a live server, distant parts may not have streamed to the client, and objects may replicate later or in a different order than in Studio testing.

How does StreamingEnabled cause infinite yield, and how do I fix it without turning streaming off?

Parts far from the player may not exist on the client, so WaitForChild never finds them. React with ChildAdded, DescendantAdded or CollectionService’s instance-added signal, set Model.ModelStreamingMode to Persistent or Atomic for must-have models, or use a timeout with a nil check.

Should I use WaitForChild or FindFirstChild?

Use WaitForChild for objects that will replicate or be created soon, especially on the client. Use FindFirstChild with a nil check for objects that should already exist; the Roblox docs describe it as the more efficient choice there.

How do I add a timeout to WaitForChild, and what happens when it runs out?

Pass seconds as the second argument, for example WaitForChild("Door", 10). If the child hasn’t appeared by then, it returns nil, so check for nil before using the result.

Why does my LocalScript wait forever for something in ServerStorage?

ServerStorage and ServerScriptService never replicate to clients, so the object can never appear for a LocalScript. Move objects the client needs into ReplicatedStorage.

Can AI fix Roblox WaitForChild errors?

Stellar AI can explain the warning and suggest corrected Luau if you paste the full warning, the script, its type and location. Start free with up to 15 Stellar Fast replies a day, no card, and test the fix in Studio.

Related guides

Want it fixed for you? The £99 Priority Script Fix is a one-off fix for a FiveM or Roblox script. Memberships start at £8 a month on the plans page.