Platform-Backend CrashLoopBackOff: "Failed to Initialize OpenID Connect Provider" (404)

Last updated: March 19, 2026

Symptom

One or more platform-backend pods enter CrashLoopBackOff with the following error in logs:

Error initializing openid connect provider: Non-success code for Discovery URL: 404
panic: failed to initialize openid connect provider

The remaining pods may continue running normally.

Root Cause

The platform-backend automatically appends /.well-known/openid-configuration to the value of OAUTH_ISSUER_URL at startup. If OAUTH_ISSUER_URL already includes that suffix, the resulting discovery URL becomes:

https://<issuer>/.well-known/openid-configuration/.well-known/openid-configuration

This doubled path returns a 404 from the OIDC provider, causing the pod to crash immediately (there is no retry logic on this startup check).

Resolution

  1. Check the current value of OAUTH_ISSUER_URL in your Helm values or environment configuration.

  2. If it ends with /.well-known/openid-configuration, remove that suffix. The value should be the bare issuer URL only:

    # Correct
OAUTH_ISSUER_URL=https://your-idp.example.com/oidc/your-client-id

# Incorrect
OAUTH_ISSUER_URL=https://your-idp.example.com/oidc/your-client-id/.well-known/openid-configuration

  3. Restart the platform-backend pods:

    kubectl rollout restart deployment <release>-langsmith-platform-backend \  -n <namespace>

Additional Checks

If OAUTH_ISSUER_URL is already correct (no suffix), verify:

  • In-cluster reachability: The OIDC provider must be reachable from within the Kubernetes cluster, not just from your workstation. Test with:

    kubectl run oidc-test --rm -it --restart=Never \  --image=curlimages/curl -n <namespace> \  -- curl -sS -o /dev/null -w "%{http_code}" \  <OAUTH_ISSUER_URL>/.well-known/openid-configuration

  • Transient failures: If only 1 of N pods is crashing and the OIDC provider is reachable, the failure may have been transient. Simply delete the crashing pod to trigger a fresh restart.