We deploy l Airbyte 2.0.1 with Helm chart v2.0.19 on Kubernetes. Airbyte keeps failing after deployment with: { "url": "https://airbyte.staging.tailstech-nonprod.com/workspaces/42482ecd-c993-477d-b92f-daeba56e567e/connections", "airbyteVersion": "2.0.1", "errorType": "HttpError", "errorConstructor": "$d", "error": { "i18nKey": "errors.http.notFound", "i18nParams": { "status": 404 }, "name": "HttpError", "requestId": "98KEVSNf2V1wLfUxoSqE5B", "request": { "url": "/api/v1/workspaces/get", "method": "POST", "headers": { "Content-Type": "application/json" }, "data": { "workspaceId": "42482ecd-c993-477d-b92f-daeba56e567e" } }, "status": 404, "response": { "message": "Internal Server Error: Could not find configuration for STANDARD_WORKSPACE: 42482ecd-c993-477d-b92f-daeba56e567e.", "exceptionClassName": "io.airbyte.commons.server.errors.IdNotFoundKnownException", "exceptionStack": [], "rootCauseExceptionStack": [] } }, "stacktrace": "HttpError: errors.http.notFound\n at fyt (https://airbyte.staging.tailstech-nonprod.com/assets/core-l0xde5f173.js:56:1032)", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36", "featureFlags": {} } What's going wrong?

The knowledge sources don’t describe this exact 2.0.1 / 2.0.19 situation, but they do show the same error pattern: the backend cannot find a workspace with the ID the UI is requesting, and returns: >

Could not find configuration for STANDARD_WORKSPACE: <workspace-id>

>

IdNotFoundKnownException

[[Docker connectors 1.6.x](https://github.com/airbytehq/airbyte/issues/59196)] In your case, the UI is POSTing:

json {   "workspaceId": "42482ecd-c993-477d-b92f-daeba56e567e" }

and the server responds 404 with that same “STANDARD_WORKSPACE” message. That means: * The Airbyte server is up and responding, but * There is no workspace with ID

42482ecd-c993-477d-b92f-daeba56e567e

in the config database, so the

/api/v1/workspaces/get

call fails. This is a data/configuration problem, not a generic “API is down” problem. Similar issues have appeared after upgrades or mis‑matched chart/platform versions, where the expected workspace or instance configuration wasn’t present and the UI then showed 404s. [[Helm upgrade 0.63.11→1.3.0](https://github.com/airbytehq/airbyte/issues/49843); [STANDARD_WORKSPACE not found](https://github.com/airbytehq/airbyte/issues/59196)] From the docs, a 404 on workspace APIs specifically means “Workspace not found” and the recommended action is to verify the workspace ID. [[Workspace errors](https://docs.airbyte.com/ai-agents/embedded/api/workspaces#error-responses)] Given only the provided sources, I can’t see why that workspace ID is missing (e.g. failed migration, wrong database, fresh install vs. existing URL), only that: * The workspace with ID

4248…567e

does not exist in the backend config store. * The UI is trying to load that non‑existent workspace, so you get 404. Based on this, the next steps (inferred from the error semantics) would be: 1. Verify that a workspace with ID

42482ecd-c993-477d-b92f-daeba56e567e

actually exists via the API (e.g.

GET /workspaces/{workspaceId}

) or DB; a 404 there confirms it’s missing. [[Public API getWorkspace](https://reference.airbyte.com/reference/start)] 2. If this is a fresh 2.x install, use the default workspace created by the platform instead of a hard‑coded old ID. 3. If this is an upgrade, ensure you’re pointing to the same config database and that migrations completed successfully; otherwise the old workspace records won’t be there. The knowledge sources don’t provide more specific remediation steps for 2.0.1 + chart 2.0.19 beyond this interpretation of the error.

@kapa.ai, how can I find the correct URL for our Airbyte web UI?

A message from kapa.ai