Even if your agent appears to be serving requests correctly — for example, logs like these show successful metadata submissions:

10/17/2025, 7:57:47 PM Successfully submitted metadata to LangSmith instance
10/17/2025, 7:57:47 PM HTTP Request: POST http://langsmith-frontend.langsmith/api/v1/metadata/submit "HTTP/1.1 204 No Content"
10/17/2025, 7:57:47 PM Successfully submitted metadata to beacon endpoint
10/17/2025, 7:57:47 PM HTTP Request: POST https://api.smith.langchain.com/v1/metadata/submit "HTTP/1.1 204 No Content"

…the LangSmith Deployments UI may still show the deployment as failed.

Understanding the Issue

The final step of the deployment process performs a health check — a request sent to your agent’s ingress endpoint to confirm it is reachable and operational.

If this step fails, the deployment will be marked as “Unsuccessful” even if your agent is actually running fine.

Common causes include:

• Network or cluster policy blocking outgoing requests to your ingress.

• Ingress requiring SSL but missing the correct CA in the certificate chain.

• TLS configuration mismatch between LangSmith and your ingress.

You can inspect the langsmith-listener pod logs for the root cause.

Look for a stack trace under the wait_for_health_check method.

Solutions:

1. Disable the Health Check

If you prefer to skip the ingress health verification step, set:

config:
  deployment:
    ingressHealthCheckEnabled: true

2. Relax Network Policy

Ensure the langsmith-listener pod can reach your ingress endpoint. You can test this manually:

kubectl exec -it <langsmith-listnerer-pod> -- curl -v https://<hostname>/lgp/<agent_id> 

3. Fix TLS Configuration

If there’s a TLS mismatch, ensure the Helm values align with your ingress configuration:

config:
  deployment:
    tlsEnabled: true # Or false

4. Address SSL Verification Issues

If SSL validation fails, can do either of the following:

• Update your ingress to use a publicly trusted CA (e.g., DigiCert).

• Mount your internal CA certificate into the pods so the LangSmith agent trusts it. Instructions here: https://docs.langchain.com/langsmith/self-host-custom-tls-certificates#mount-internal-cas-for-tls

2: LangSmith Deployments Agent is Running, but Studio and Assistants fail with "Internal Server Error"

The agent is up and running, but accessing the Assistants panel and the Studio fails with Internal Server Error.

Additionally, agent server logs something of the following, failing to reach the langsmith-frontend service.

Understanding the Problem

Some of the endpoints on your agent rely on LangSmith authentication. Assistants and the studio are 2 of them. In order to authenticate those requests, your agent routes requests to the langsmith-frontend pod before returning information. This inter-service communication can fail, causing the endpoints to return an error.

Solution

• Relax your network policy to allow cross-service communication from your agent to langsmith-frontend

• If you are using Istio, make sure that your AuthorizationPolicy enabled communication between your agent and LangSmith frontend.