Ollama Timed Out Waiting for Server to Start: Fixes

Error: timed out waiting for server to start only appears on macOS and Windows, and it means one specific thing. The Ollama CLI found no server, launched the Ollama desktop app itself, then checked for a server every half second for 5 seconds and got no answer. That 5 seconds is a fixed number in the CLI. So first, wait ten seconds and run the same command again: if it works, the app was simply slow to start. If it fails again, the server is not coming up at all, and the reason is in server.log (~/.ollama/logs/server.log on macOS, %LOCALAPPDATA%\Ollama\server.log on Windows). Or the CLI is waiting on a different address from the one the app listens on.

On Linux this exact message does not exist. There, the same situation prints could not connect to ollama server, run 'ollama serve' to start it, because the Linux CLI has no desktop app to launch. That case is covered in Ollama connection refused on port 11434.

Everything below was read from ollama/ollama at tag v0.40.13 (released 28 October 2026), from the official troubleshooting docs, or quoted from the GitHub issue linked next to it.

What does the CLI do before it times out?

It sends a heartbeat, launches the app if nothing answered, and then gives the app 5 seconds. Almost every command that needs a server (run, list, pull, ps, show, stop, rm, cp, push, signin) runs a pre-check first. It sends a HEAD / request to whatever address OLLAMA_HOST points at (default 127.0.0.1:11434). If that request is refused, the CLI tries to start the desktop app, then waits in this loop from cmd/start.go:

func waitForServer(ctx context.Context, client *api.Client) error {
	// wait for the server to start
	timeout := time.After(5 * time.Second)
	tick := time.Tick(500 * time.Millisecond)
	for {
		select {
		case <-timeout:
			return errors.New("timed out waiting for server to start")
		case <-tick:
			if err := client.Heartbeat(ctx); err == nil {
				return nil // server has started
			}
		}
	}
}

How the app gets launched differs by platform:

• macOS (cmd/start_darwin.go): the CLI only tries if the ollama you ran is a symlink into an Ollama.app bundle, which is what the app's own /usr/local/bin/ollama link is. It runs open -j -a <that bundle> --args --fast-startup. A Homebrew formula install is not inside an app bundle, so it never gets this far and never sees this error.
• Windows (cmd/start_windows.go): the CLI first checks whether OllamaSetup.exe is running and stops with upgrade in progress... if it is. Then it looks for ollama app.exe next to itself, in %LOCALAPPDATA%\Ollama, and on PATH, and runs it with --hide --fast-startup. If it finds none, you get could not locate ollama app instead.

Two details from the app side explain why a healthy machine can still hit the limit. The desktop app waits one second (restartDelay in app/server/server.go) before it starts ollama serve at all. And the app gives its own server 10 seconds to become ready (ui.WaitForServer(ctx, 10*time.Second) in app/cmd/app/app.go). The CLI allows half of that. A cold start that the app considers normal can be too slow for the CLI.

Which version of the message do you have?

Step 1: run it again, then read two logs

Retry once after ten seconds. If it still fails, the two log files tell you which of the causes below you have. The desktop app writes its own messages to app.log and pipes everything ollama serve prints into server.log, in the same folder.

macOS (Terminal):

sleep 10; ollama list
tail -n 40 ~/.ollama/logs/server.log
tail -n 40 ~/.ollama/logs/app.log
curl -s http://127.0.0.1:11434/api/version

Windows (PowerShell):

Start-Sleep 10; ollama list
Get-Content "$env:LOCALAPPDATA\Ollama\server.log" -Tail 40
Get-Content "$env:LOCALAPPDATA\Ollama\app.log" -Tail 40
curl.exe -s http://127.0.0.1:11434/api/version

Then match what you found:

Cause 1: the app was just slow to start

If the second attempt works, nothing is broken. The CLI gave up at 5 seconds, but the app kept starting in the background and finished a moment later. The arithmetic above makes this unsurprising: one second of built-in delay, then the app's and the server's own startup, all inside a 5-second budget.

The first command after a reboot or an update is the usual moment. On both macOS and Windows, a launch from the CLI (which passes --fast-startup) also skips any pending update (the app logs deferring pending update for fast startup), so updating does not add to the wait. That only happens when the app was started by the CLI.

There is no setting that lengthens the CLI's wait. The value is a constant in cmd/start.go and is not read from any environment variable. If you hit this every morning, open the Ollama app yourself before your first command, or add it to your login items (macOS: System Settings, General, Login Items). Then the server is already running when you type.

Cause 2: the CLI is checking a different address

The CLI checks whatever OLLAMA_HOST says in your terminal. The app's server takes its settings from somewhere else. If the two disagree, the app starts correctly on 127.0.0.1:11434 while the CLI watches another address for 5 seconds and reports a timeout.

The CLI side is api.ClientFromEnvironment(), which reads OLLAMA_HOST through envconfig.Host(). The server side is different on each platform. On macOS the app gets its environment from launchd, which is why Ollama's FAQ tells you to use launchctl setenv rather than your shell profile. On Windows, an app started from the Start menu or at sign-in gets your saved user variables, while an app the CLI launches inherits the terminal's environment. The mismatch bites when the app was already running from sign-in: the CLI's launch attempt just hands over to that running copy (see Cause 5), which keeps listening where it was. The app's own "expose Ollama to the network" setting also changes the server's bind address to 0.0.0.0.

Three mismatches cause most of these:

1. OLLAMA_HOST=http://localhost with no port. envconfig.Host() treats an http:// address without a port as port 80, not 11434. We checked this on macOS with Homebrew Ollama 0.12.3 and a server running on 11434. OLLAMA_HOST=http://localhost ollama list still failed, because the CLI was knocking on port 80. On that build, with no app installed, the failure prints the older could not find ollama app message. With the app installed, the same mismatch ends in this timeout.
2. OLLAMA_HOST points at another machine. If that machine is up but Ollama is not running on it, the heartbeat is refused. The CLI then launches your local app, which starts on your machine, while the CLI keeps waiting on the remote address. (If the machine is off entirely, the error is a network timeout instead, and the CLI does not try to launch anything.)
3. A custom port in your shell but not in the app's environment, or the other way round.

Check both sides:

# macOS: what the CLI sees, then what launchd gives the app
echo "$OLLAMA_HOST"
launchctl getenv OLLAMA_HOST

# Windows: this terminal, then your saved user variable
echo $env:OLLAMA_HOST
[Environment]::GetEnvironmentVariable('OLLAMA_HOST', 'User')

The fix is to make them agree. Either remove the variable from your terminal (unset OLLAMA_HOST on macOS, Remove-Item Env:OLLAMA_HOST in PowerShell), or set the same value for the app: launchctl setenv OLLAMA_HOST "127.0.0.1:11434" on macOS, or a user environment variable on Windows. Then quit and reopen the app. The longer version of this trap is Cause 3 of our connection refused guide.

Cause 3: the server cannot open its port

ollama serve exits at once if it cannot bind 11434, and the CLI waits on a server that will never answer. The cleanest example is issue #12684 (Windows, Ollama 0.12.6). The CLI printed ollama server not responding - timed out waiting for server to start, server.log had

Error: listen tcp 0.0.0.0:11434: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

and app.log showed ollama exited err="exit status 1" over and over. An Ollama collaborator asked for these two commands, run in an Administrator PowerShell:

netstat -bano | Select-String -Pattern 11434 -Context 0,1
netsh interface ipv4 show excludedportrange protocol=tcp

The second one is the interesting one. The reporter's output listed excluded ranges 11307-11406 and 11407-11506, and 11434 falls inside the second. Windows had reserved the port, so nothing visible was using it, yet nothing could bind it. In that thread a reboot resolved it.

The desktop app already handles the most common version of this problem. When ollama serve exits with status 1, app/server/server.go assumes a port conflict and stops any other Ollama server it finds, once, before retrying. So a leftover Ollama process gets cleared for you. A reserved port range or a non-Ollama program on 11434 does not.

On macOS, see who holds the port with:

lsof -nP -iTCP:11434 -sTCP:LISTEN

If the port is reserved or taken by another program and you cannot free it, move Ollama to a port outside every range netsh printed. Set the same OLLAMA_HOST (for example 127.0.0.1:11600, if that is clear on your machine) as a user variable, so the app and the CLI both read it. For a port taken by a second Ollama, see address already in use.

Cause 4 (Windows): the app cannot find its own server program

If server.log is empty and ollama serve works when you type it yourself, check your PATH for a stray quotation mark. This is the strangest cause on the page, and it comes up repeatedly in 2026 threads.

In v0.40.13 the desktop app finds the ollama program through resolvePath("ollama") in app/server/server.go. It first looks for a file called ollama, with no extension, next to the app. On Windows that file is ollama.exe, so the check never matches, and the lookup falls through to exec.LookPath, meaning PATH. If PATH is broken, the tray icon still appears, but the server never starts and never writes a line.

What broken looks like, from the threads:

• Issue #16404 (June 2026): the reporter saw the GUI open, a timeout in the logs, and ollama not recognised in CMD. The Ollama collaborator's diagnosis was one character: "Your PATH has a " after Wireguard." The same thread shows a second PATH mistake: an entry ending in \ollama.exe. PATH entries must be folders, not files.
• Issue #18507 (September and October 2026): after the original bug in that thread was fixed (Cause 5), one user found an unmatched quotation mark in PATH, and a second wrote up the same fix in detail. Their symptoms: tray app launched but never usable, Error: timed out waiting for server to start, server.log at 0 KB, manual ollama serve working at once. They saw it on both 0.33.x and 0.40.x while PATH was malformed.

The second write-up adds the detail that makes the bad entry findable. PowerShell's $env:Path is a merged view of your user PATH and the machine PATH, so check each one on its own and list the entries that do not exist:

# Your user PATH and the machine PATH, separately
[System.Environment]::GetEnvironmentVariable('Path', 'User')
[System.Environment]::GetEnvironmentVariable('Path', 'Machine')

# Entries that point at nothing (a stray " makes every entry after it invalid)
([System.Environment]::GetEnvironmentVariable('Path', 'User') -split ';' | Where-Object { $_ }) | Where-Object { -not (Test-Path $_) }
([System.Environment]::GetEnvironmentVariable('Path', 'Machine') -split ';' | Where-Object { $_ }) | Where-Object { -not (Test-Path $_) }

# Which ollama.exe a terminal finds
where.exe ollama

Fix it in Settings: search for "environment variables", open "Edit environment variables for your account" (or the system one, which needs admin rights, if the bad entry is there), and remove the stray " or replace the .exe entry with its folder. Copy the old value somewhere first, because a bad edit can break other programs. Then sign out of Windows and back in, which is what the second user did, so every process picks up the corrected PATH. Our Ollama on Windows guide covers the rest of the Windows install.

Cause 5 (Windows): a tray icon with no server behind it

On Windows, a second copy of the app does not start a new server. It hands over to the copy already running and exits. That is handleExistingInstance in app/cmd/app/app_windows.go, which logs existing instance found, exiting. The running app restarts a server that exits, so this only sticks when the server never comes up at all: a launcher bug, or a server that fails on every start. Then the CLI's launch attempt does nothing, and you get the timeout every time.

Issue #18507 is this case on Windows 11 with Ollama 0.34.1: tray icon present, curl http://127.0.0.1:11434/api/version failing, ollama list returning Error: timed out waiting for server to start, and app.log showing "existing instance found, exiting" then "ollama server not ready after retries". The reporter confirmed on 18 September 2026 that 0.34.2 fixed it, and that 0.33.1 and 0.34.1 had both failed.

Fix: quit Ollama from the tray icon (right-click, Quit), start it again from the Start menu, and update if you are on an older build. If the tray will not quit:

taskkill /IM "ollama app.exe" /F
taskkill /IM ollama.exe /F

Cause 6 (macOS): the models folder is on a drive that is not there

If your models live on an external drive, the server can hang or fail until that drive is mounted and readable. Issue #11629 (macOS, Ollama 0.10.1) began as a "this release broke everything" report: every CLI command returned ollama server not responding - timed out waiting for server to start, and the app window was blank. The reporter later found the cause. The app had started at login while the external volume holding the models was not yet mounted. Mounting it fixed everything, and a second user with ~/.ollama/models symlinked to an external SSD confirmed the same.

A related trap is in issue #13404. It is a Homebrew install, so it shows the "could not find ollama app" wording rather than this one, but the cause carries over. The server hung on an external-drive symlink because macOS was waiting for Ollama to be granted access to the drive. One commenter found the prompt waiting on screen after connecting by VNC, and fixed it under System Settings, Privacy & Security, Full Disk Access.

Fix: mount the drive before you start Ollama, grant access if macOS asks, or move the models back to the internal disk. Setting the models location properly, instead of with a symlink, is covered in OLLAMA_MODELS not working.

Run the server yourself to see the real error

Quitting the app and running ollama serve in a terminal puts the server's startup output in front of you. It is the quickest way to separate "the server cannot start" from "the app cannot start the server".

# macOS: quit Ollama from the menu bar first
ollama serve
# in a second terminal
ollama list

# Windows: quit Ollama from the tray first
ollama serve
# in a second PowerShell window
ollama list

• If ollama serve fails, the error it prints is your diagnosis. A bind error is Cause 3, and a model-directory error is Cause 6.
• If ollama serve works and the app still does not, the server is fine and the problem is how the app launches it, which is Causes 4 and 5 on Windows. That is exactly what the reporters in #18507 and #16404 saw.

When you are done, stop that ollama serve (Ctrl+C) before reopening the app. Otherwise the two compete for port 11434.

Honest limitations

• We did not reproduce the 5-second timeout itself. It needs the desktop app, and the machine we tested on runs the Homebrew formula (Ollama 0.12.3). We did reproduce the address mismatch in Cause 2 there, which prints the no-app variant of the error. Everything else on this page comes from the source code at v0.40.13 or from the linked issue threads.
• The Windows causes come from user reports, confirmed by collaborators where noted. Cause 4 follows from the code as it stands in v0.40.13. A later release could change how the app finds ollama.exe, and the first thread to report a fix will be the place to check.
• Version boundaries are exact only where we checked them. The prefix change between v0.15.4 and v0.15.5 was verified by reading both tags. The 0.34.2 fix in Cause 5 is the reporter's statement, not something we tested.
• We do not list "reinstall Ollama" as a fix. Reinstalling helped none of the reporters above, because none of the causes are in the installed files.

FAQ

Can I make Ollama wait longer than 5 seconds?

Not from the CLI. The limit is a constant in cmd/start.go and no environment variable changes it. OLLAMA_LOAD_TIMEOUT is a different setting: it controls how long a model load may stall, not how long the CLI waits for the server. Start the app before your first command, or run the command a second time.

Why does it only happen on the first command after a reboot?

That is when the server is not running yet, so the CLI has to launch the app and the startup has to beat 5 seconds. Every later command finds the server already up and skips the launch. If the first command fails and the second works, you have Cause 1 and nothing to fix.

Does "timed out waiting for server to start" happen on Linux?

No. The Linux CLI has no app to launch, so it never starts the 5-second wait. On Linux the same situation prints could not connect to ollama server, run 'ollama serve' to start it, and the fix is to start the service with sudo systemctl start ollama or run ollama serve.

Why does ollama serve work but the Ollama app does not?

Because they start the server differently. When you type ollama serve, your terminal runs it with your PATH and environment. When the tray app starts it, the app has to find ollama.exe through PATH and reads your saved user variables. A broken PATH entry (Cause 4) or a stuck tray instance (Cause 5) breaks the app's route only.

What is the difference between this and "timed out waiting for llama-server to start"?

They are unrelated. This page is about the server not answering within 5 seconds. timed out waiting for llama-server to start comes from the running server, when a model stops making loading progress for OLLAMA_LOAD_TIMEOUT (5 minutes by default). That one is covered in Ollama stuck loading a model.

Why does ollama -v say "could not connect to a running Ollama instance"?

ollama -v does not launch the app. It asks the server for its version and, if nothing answers, prints Warning: could not connect to a running Ollama instance, followed by the client version. It is the same "no server" state, without the launch attempt or the 5-second wait.

Should I set OLLAMA_HOST to 0.0.0.0 to fix this?

No. 0.0.0.0 changes which network interfaces the server listens on. It does nothing for the CLI's timeout, and it exposes the API to your network. If you need remote access, read securing an Ollama server first.

Other Ollama errors: every error string, indexed · could not locate ollama app · connection refused on 11434 · stuck loading a model

Sources

• ollama/ollama v0.40.13: cmd/start.go (waitForServer, the 5-second limit and the error string)
• cmd/start_darwin.go and cmd/start_windows.go (how the CLI launches the app on each platform)
• cmd/cmd.go (checkServerHeartbeat; compared with v0.15.4 for the old "server not responding" prefix)
• app/server/server.go (start delay, port-conflict retry, resolvePath) and app/cmd/app/app.go (the app's own 10-second wait)
• envconfig/config.go (Host() and the port-80 default for http://)
• Ollama troubleshooting docs, Windows docs and macOS docs (log locations, app.log and server.log)
• Issues: #18507 (tray app with no server, fixed in 0.34.2 per the reporter; PATH quotes), #16404 (stray quote in PATH), #12684 (port in a Windows excluded range), #11629 (models on an unmounted volume), #13404 (Full Disk Access prompt for an external drive)