For source creation in the Airbyte UI, the same logging mechanisms apply as for sync jobs, but the docs only describe how to view logs at the connection/job level, not specifically for “create source” actions. What you can do based on the documented behavior: - After you’ve created a source and used it in a connection (e.g., a test sync), go to that connection’s Job History tab and open View logs from the

⋯

menu to see detailed logs for that job. [[Browsing logs](https://docs.airbyte.com/platform/operator-guides/browsing-output-logs)] - From the same menu you can Download logs if you need to search across attempts locally. [[Browsing logs](https://docs.airbyte.com/platform/operator-guides/browsing-output-logs)] For Airbyte Open Source, the documentation also notes that additional server/worker logs are available on the Docker volumes outside the UI, but it does not give a path or a specific section for “source creation” logs. [[Browsing logs](https://docs.airbyte.com/platform/operator-guides/browsing-output-logs)] So, the knowledge sources do not explicitly document a dedicated UI location for logs tied only to the “create source” step; they only cover job-level logs and general server/worker logs.

For an HTTP 502 when creating a source in the Airbyte UI, the available information is limited, but here’s what the knowledge sources show and where to look: 1. Check worker / server logs (abctl / Kubernetes / Docker) In recent abctl-based installs, 502s during “Test the Source” or source creation are often surfaced in the worker logs (e.g.,

airbyte-abctl-worker

). One open issue shows a 502 on source creation with related errors only visible in the worker logs, not in the UI. [[source-file 502 issue](https://github.com/airbytehq/airbyte/issues/65574)] - If you installed with

abctl

(local, EC2, Azure VM, etc.), run

kubectl logs

against the worker pod (label

<http://app.kubernetes.io/name=worker|app.kubernetes.io/name=worker>

or similar in the

airbyte-abctl

namespace) and the server pod to see the underlying error. [[source-file 502 issue](https://github.com/airbytehq/airbyte/issues/65574); [source-postgres 502 issue](https://github.com/airbytehq/airbyte/issues/65567)] - On Kubernetes Helm installs, similar 5xx errors on “Test the Source” have been traced via the worker/launcher pods (e.g.,

airbyte-workload-launcher

,

source-<connector>-check

pods). [[Airbyte 1.2.0 EKS 500](https://github.com/airbytehq/airbyte/issues/48809)] 2. Use the browser Network tab In multiple forum threads about 502/504 during source checks, users were asked to capture the response payload of the failing request from the browser’s Network tab (e.g.,

POST /api/v1/scheduler/sources/check_connection

). [[Kubernetes 502 thread](https://discuss.airbyte.io/t/594); [502 Timeout When Creating Connection](https://discuss.airbyte.io/t/1207)] This can confirm whether the 502 is coming from: - Your ingress / proxy (e.g., GKE/GCP 502 page), or - Airbyte’s own backend. 3. Job / check logs in the UI (if the check job is created) When you click Test the Source, Airbyte schedules a check job. If that job is created successfully, you can sometimes see it under a connection’s Job History and open View logs from the

⋯

menu. [[Browsing logs](https://docs.airbyte.com/platform/operator-guides/browsing-output-logs)] However, the docs do not explicitly describe a dedicated “source creation” log view; they only cover job-level logs and general server/worker logs. 4. **What the docs do not say** The documentation and issues do not provide a single, definitive root cause or fix for “HTTP 502 when creating a source”; they only show that: - 5xx errors on source creation/check are typically debugged via worker/server logs and the browser Network tab. [[source-file 502 issue](https://github.com/airbytehq/airbyte/issues/65574); [Kubernetes 502 thread](https://discuss.airbyte.io/t/594)] - In some cases, upstream infrastructure (ingress / timeout) can be involved. [[502 Timeout When Creating Connection](https://discuss.airbyte.io/t/1207)] If you can share: - How you deployed Airbyte (abctl local/EC2, Docker, Helm/Kubernetes, etc.), and - The exact error body from the failing

POST /api/.../sources/check_connection

in your browser Network tab, plus any relevant worker/server log snippets, I can help you interpret those logs based strictly on the patterns shown in the linked issues and docs.

The knowledge sources don’t explicitly show this exact log snippet, but they do show very similar

JsonSchemaValidator

errors for MongoDB and other connectors, so I can only answer based on those patterns. From your log: -

errors: $.cluster_type: must be the constant value 'ATLAS_REPLICA_SET'

-

required property 'username' not found

-

required property 'password' not found

-

errors: $.mode: does not have a value in the enumeration ["disable"], $.mode: must be the constant value 'disable'

-

errors: $.mode: does not have a value in the enumeration ["allow"], $.mode: must be the constant value 'allow'

-

ConfigReplacer(getAllowedHosts): All allowedHosts values are un-replaced. Check this connector's configuration or actor definition - [${connection_string}]

These are typical JSON-schema validation errors raised when the connector configuration doesn’t match its spec (wrong

cluster_type

, missing required fields, or feature-flag / “allowed hosts” config not being substituted). Very similar patterns appear for: - MongoDB source: missing `host`/`port`/`instance` or wrong enum values. [[Mongodb to s3](https://discuss.airbyte.io/t/774)] - Other connectors where credentials or modes are enforced by `const`/`enum` in the spec (e.g., Snowflake OAuth, MySQL → BigQuery). [[JsonSchema oneOf](https://discuss.airbyte.io/t/914); [MySQL→BQ validation](https://discuss.airbyte.io/t/3531)] Given the

cluster_type

and

connection_string

hints, this is almost certainly the MongoDB v2 source connector, which has a

cluster_type

field (e.g., Atlas vs self‑managed replica set) and a

connection string

parameter in its configuration. [[MongoDB v2 config](https://docs.airbyte.com/integrations/sources/mongodb-v2#configuration-parameters)] So: - Yes, this error is related to the same connector whose config you’re editing (very likely the MongoDB v2 source). - The logs indicate that the values you’re sending for: -

cluster_type

-

username

-

password

- any

mode

fields (e.g., for “allowed hosts” / network access) do not satisfy the connector’s JSON schema (wrong enum/const or missing required fields), and

${connection_string}

in

allowedHosts

is not being replaced. The knowledge sources do not provide a step‑by‑step fix for this exact combination of messages, but they consistently show that resolving such errors requires aligning your source configuration with the connector’s documented spec (correct

cluster_type

, required credentials, and valid enum values). [[Mongodb to s3](https://discuss.airbyte.io/t/774); [MongoDB v2 config](https://docs.airbyte.com/integrations/sources/mongodb-v2#configuration-parameters)]

From the logs and docs we have, there are a few known Google Sheets connection issues and how to narrow them down: 1. Sheets with BigQuery “Data Connector” tabs If your spreadsheet has a tab created by the Google Sheets → BigQuery “Data Connector” (e.g. a tab named

Connected sheet 2

), the Google Sheets source can fail the connection check with an error like:

HttpError 400 ... "Unable to parse range: Connected sheet 2!1:1"

even if that tab is not selected in the sync. [[Forum thread](https://discuss.airbyte.io/t/2600)] Workaround (documented): move the BigQuery‑connected tab to a different spreadsheet and point Airbyte only at the “plain” spreadsheet. [[Forum thread](https://discuss.airbyte.io/t/2600)] 2. Network / DNS issues (Open Source) If you see errors like

Unable to find the server at <http://oauth2.googleapis.com|oauth2.googleapis.com>

in the job logs, it’s a DNS / outbound network problem from the connector container, not your credentials. [[Source GS DNS](https://discuss.airbyte.io/t/2626)] In that case you need to ensure the Docker/Kubernetes network where Airbyte runs has internet access and can resolve

<http://oauth2.googleapis.com|oauth2.googleapis.com>

. [[Source GS DNS](https://discuss.airbyte.io/t/2626)] 3. Auth / config validation errors When creating or testing the source, Airbyte may log JSON schema validation errors such as missing

client_id

,

client_secret

,

refresh_token

, or malformed

service_account_info

. [[GS config errors](https://discuss.airbyte.io/t/2600)] Make sure your config matches one of the supported methods: - Open Source (recommended): Service Account Key JSON pasted exactly as downloaded. [[GS OSS setup](https://docs.airbyte.com/integrations/sources/google-sheets#for-airbyte-open-source)] - OAuth: correct client ID, client secret, and refresh token, with

<https://www.googleapis.com/auth/spreadsheets.readonly>

scope. [[GS source](https://docs.airbyte.com/integrations/sources/google-sheets)] 4. Where to see the detailed error - In Open Source, the connection test runs a

check

job; its logs look like the snippets in the forum posts and are stored in the workspace logs (and surfaced in the UI when available). [[GS DNS logs](https://discuss.airbyte.io/t/2626); [GS BigQuery tab logs](https://discuss.airbyte.io/t/2600)] Because your last pasted log is for a different connector (MongoDB‑style fields like

cluster_type

,

username

,

password

), I can’t see your actual Google Sheets error in the provided sources. If you can share: - The exact error message from the Google Sheets source check (or a snippet like the ones above), and - Whether your sheet has a BigQuery “Connected sheet” tab, I can map it precisely to one of the documented issues/workarounds above.