Helm chart v2: manifest-server liveness/readiness probes hit /health, which the server 307-redirects to /health/

[RafPe]

What happened

With Helm chart 2.1.0 (also present in 2.1.1 and current main), every kubelet probe against the manifest-server logs a redirect followed by a second request:

airbyte-manifest-server INFO:  10.89.52.226:52772 - "GET /health HTTP/1.1" 307 Temporary Redirect
airbyte-manifest-server INFO:  10.89.52.226:52776 - "GET /health/ HTTP/1.1" 200 OK

Root cause

The chart hardcodes the probe path as /health (no values override exists):
https://github.com/airbytehq/airbyte-platform/blob/main/charts/v2/airbyte/templates/airbyte-manifest-server/deployment.yaml#L97 (and L108 for the readiness probe)

But the manifest-server only registers the route with a trailing slash — APIRouter(prefix="/health") + @router.get("/"):
https://github.com/airbytehq/airbyte-python-cdk/blob/main/airbyte_cdk/manifest_server/routers/health.py

FastAPI's default redirect_slashes=True turns every GET /health into a 307 to /health/.

Impact

Probes still pass (the kubelet's HTTP client follows the redirect), so this is not an availability bug — but it doubles the request count and log volume for every liveness/readiness check on every manifest-server pod, and the permanent 307s are misleading when scanning logs or HTTP metrics.

Suggested fix

Either (or both):

• Chart: change the two literals in airbyte-manifest-server/deployment.yaml to /health/.
• CDK: register the health route without the trailing-slash redirect, e.g. @router.get("") alongside @router.get("/"), so /health answers 200 directly.

The chart fix is a two-character diff and immediately effective; the CDK fix also covers anyone probing or monitoring /health outside the chart.

Environment

• Helm chart: airbyte 2.1.0 (from https://airbytehq.github.io/charts), also reproduced with 2.1.1
• manifestServer.image: airbyte/manifest-server:7.10.0 (chart default)
• Airbyte Community (self-managed), Kubernetes 1.33

---

Internal Tracking: https://github.com/airbytehq/oncall/issues/13203

[octavia-bot]

AI Triage Starting...

Thank you for opening this issue! I'm an AI assistant that will do an initial review and may:

• Ask clarifying questions if needed
• Suggest relevant documentation or workarounds
• Flag this for internal visibility

Note: Community issues are reviewed on a best-effort basis and do not have a guaranteed response time. For additional help:

• Join the Airbyte Community Slack to connect with other users and community members
• If you're an Airbyte Cloud customer, you can open a support ticket or contact your account representative, referencing this issue URL

View playbook

• 🔗 Session URL: https://app.devin.ai/sessions/0f2ba415ea5149e0a2c7910a0a4d7413

✅ Devin AI session created successfully!

[airbyte-support-bot]

Hi Rafal Pieniazek (@RafPe), thank you for reporting this, and for the detailed writeup with logs, environment details, and pointers to the relevant code!

We're looking into this. We've escalated it to our team for investigation: airbytehq/oncall#13203

No action is needed from you at this time. If you happen to have additional context — for example whether you see the same pattern on other v2 chart components' probes — feel free to add it here. Please make sure to mask or remove any sensitive information (API keys, passwords, tokens, connection strings) from anything you share.

---

Need more help? Join Airbyte Community Slack for peer support, or if you're a Cloud customer, open a support ticket referencing this URL.