Server did not respond within 60s

[Dr-LEO-MS]

Server did not respond within 60s. i facing this issue in my terminal

[diegosouzapw]

Hey @Dr-LEO-MS! "Server did not respond within 60s" is a generic upstream timeout -- I can't tell which provider/model triggered it from the screenshot alone. Could you share:

1. Which provider + model you were calling.
2. The request log line from ~/.omniroute/logs/ around that timestamp (or Dashboard -> Providers -> [that provider] -> connection status).

That'll tell us if it's a slow/stuck upstream connection (provider-side) or something on OmniRoute's admission/routing side.

[diegosouzapw]

@Dr-LEO-MS -- still seeing the 60s timeout?

It is a generic upstream timeout, so it identifies nothing on its own. The three things that make it diagnosable: which provider and model you were calling, whether the request was streaming or not, and whether it fails every time or intermittently.

If there is no reply I will close this in 7 days for inactivity.

[Dr-LEO-MS]

this issue was resolved . thank you for your support. sorry for the late reply

[Dr-LEO-MS]

ominiroute is working but why its showing every time in terminal cmd. i shared my logs
app.log

[diegosouzapw]

@Dr-LEO-MS thanks for the log, and glad the original failure is resolved. The log answers your remaining question, and it also corrects me: I diagnosed this wrong twice.

That message is not an upstream timeout

I told you it was "a generic upstream timeout". It is not. It comes from the CLI, not from any provider (bin/cli/commands/serve.mjs:493). The CLI starts the server, polls /api/monitoring/health for 60 seconds, and prints that warning if the health route has not answered by then. It is a startup readiness warning, which is exactly why you see it every time while OmniRoute works fine.

Why it fires on your machine

Your log shows the boot taking about 6 minutes:

08:05:14  first startup component
08:05:35  schema migrations applying (api_keys columns)
08:11:25  EmbedWsProxy / LiveWS finally listening

The health route answers well past the 60-second budget, so the warning always prints, then the server comes up anyway. You are on Windows with a global npm install, and Windows cold starts are the slow case the 60-second budget was already raised for (it used to be 15 s). Six minutes is beyond it.

The warning is cosmetic for you. There is no way to raise the budget today, since it is hardcoded at the call site (bin/cli/utils/pid.mjs:76), so I will open an issue to make it configurable.

Three real things in your log, in priority order

1. Your dashboard password is still the default.

[AUTH][SECURITY] Management password is set to the well-known default "CHANGEME"

Anyone who can reach your dashboard can sign in. Change it now.

2. You are accepting anonymous API traffic.

[clientApiPolicy] invalid bearer presented to /api/v1/models but REQUIRE_API_KEY=false — falling through to anonymous

A client is sending a key that does not match, and the request is served anyway because REQUIRE_API_KEY is off. Set it to true unless the instance is strictly loopback-only.

3. A real bug, and it is already fixed.

[Cleanup] Error cleaning compression_run_telemetry: no such table

compression_run_telemetry is created lazily on first write, never by a migration, and in 3.8.50 the cleanup job queries it with no existence guard (src/lib/db/cleanup.ts:376 at tag v3.8.50). On an instance that never ran compression, the table does not exist and the job throws every cycle. The current branch adds both ensureCompressionRunTelemetryTable() and a tableExists guard, so this disappears in the next release. Harmless in the meantime, it only aborts that one cleanup pass.

[diegosouzapw]

Closing for inactivity -- feel free to reopen if you still hit this, or open a fresh issue with a current log. Thanks!