https://prefect.io logo
Join Slack
Powered by
<@ULVA73B9P> I'm facing issues with prefect server...
# ask-marvin
j
@Marvin I'm facing issues with prefect server and worker deployment on Kubernetes. I triggering a large scale of runs, and I'm running into issues where worker is frequently restarting. On debugging the issue these are my findings • worker is failing to come back online due to failing to connect to the server
m
✅ thought for 448.3 seconds
Thanks for the details — sounds like your workers are crash-looping because they can’t reach your Prefect Server API. Let’s triage systematically and harden the setup. I’ll assume Prefect 3.x unless you tell me otherwise. First, a few quick questions to pinpoint the cause: - How did you deploy Server and workers (Helm charts, manifests, which versions)? - What’s the exact 
PREFECT_API_URL
set on your worker pods? - Are you using Ingress/TLS for Server? Any custom certs? - Do you have NetworkPolicies between namespaces? - Can you share a few lines from the worker logs around the restart? e.g. name resolution errors, connect timeouts, SSL errors, or 401s? - Roughly how many runs are triggered at once and what’s your work pool concurrency? Core checks and fixes 1) Verify connectivity from worker pod to Server - From a worker pod:
Copy code
# DNS resolution
getent hosts prefect-server.prefect.svc.cluster.local

# API health (cluster-internal service)
curl -sS -m 5 <http://prefect-server.prefect.svc.cluster.local:4200/api/health>

# If using ingress/TLS from inside cluster
curl -sS -m 10 -v <https://your.domain.tld/api/health>
- If the first two fail, prefer using the cluster service FQDN for 
PREFECT_API_URL
instead of the Ingress hostname (unless you require TLS and external routing in-cluster). - If TLS is involved and you use a custom CA, mount it and point workers to it with 
PREFECT_API_SSL_CERT_FILE
. As a last resort for testing only, you can use 
PREFECT_API_TLS_INSECURE_SKIP_VERIFY=true
. Relevant docs: - Self-hosted (Server) guide - Settings reference 2) Ensure the worker knows the correct API URL - For in-cluster Server, a common value is:
Copy code
PREFECT_API_URL=<http://prefect-server.prefect.svc.cluster.local:4200/api>
- For Ingress/TLS:
Copy code
PREFECT_API_URL=<https://your.domain.tld/api>
Make sure the value is reachable from the worker pod. 3) Add worker healthchecks and sane Kubernetes probes - Start workers with a healthcheck webserver and probe that endpoint instead of killing the container on transient API hiccups. - Healthcheck endpoint: 
/health
(HTTP 200 = healthy; 503 = temporarily unhealthy) - Default port: 8080 (configurable via 
PREFECT_WORKER_WEBSERVER_PORT
) - Docs: Worker healthchecks Example container command and probes (adjust to your manifest/Helm):
Copy code
args:
  - prefect
  - worker
  - start
  - -p
  - my-work-pool
  - --with-healthcheck
env:
  - name: PREFECT_API_URL
    value: <http://prefect-server.prefect.svc.cluster.local:4200/api>
  - name: PREFECT_LOGGING_LEVEL
    value: DEBUG
  - name: PREFECT_API_REQUEST_TIMEOUT
    value: "120"
  - name: PREFECT_WORKER_WEBSERVER_PORT
    value: "8080"
ports:
  - name: health
    containerPort: 8080
readinessProbe:
  httpGet:
    path: /health
    port: health
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
livenessProbe:
  httpGet:
    path: /health
    port: health
  initialDelaySeconds: 60
  periodSeconds: 20
  timeoutSeconds: 5
  failureThreshold: 6
startupProbe:
  httpGet:
    path: /health
    port: health
  periodSeconds: 10
  failureThreshold: 18
Note: The healthcheck threshold is tied to polling cadence; by default a worker becomes “unhealthy” only after a long lapse, minimizing false restarts. 4) Control concurrency to avoid API/DB overload during spikes - Set a work pool concurrency limit to prevent thundering herds:
Copy code
prefect work-pool set-concurrency-limit "my-work-pool" 50
- Consider multiple smaller worker replicas and a per-pod limit (so 1 pod doesn’t try to claim too many runs at once). - Docs: Work pools 5) Scale and harden Prefect Server - Run multiple Server replicas behind a ClusterIP/Service. - Ensure Postgres is healthy; consider PgBouncer if connections spike.
- Increase DB timeouts on Server if migrations or queries time out during load:
Copy code
PREFECT_SERVER_DATABASE_TIMEOUT=60
- Allocate sufficient CPU/memory for Server; watch for OOMKills. - Helm guidance: Server Helm 6) Network policies and DNS - If using NetworkPolicies, allow worker egress to Server service on 4200/TCP. - Verify CoreDNS stability; consider bumping 
PREFECT_API_REQUEST_TIMEOUT
to handle slower API/DNS responses during surges. 7) Logging and observability on workers - Enable debug logging to confirm what’s failing:
Copy code
PREFECT_LOGGING_LEVEL=DEBUG
- Look for: - 
httpx.ConnectError
or 
ConnectTimeout
- 
Name or service not known
(DNS) - 
SSL: CERTIFICATE_VERIFY_FAILED
(custom CA/TLS) - 
401 Unauthorized
(if you’ve enabled auth on self-hosted server) 8) Kubernetes resources - Check worker pod limits; during large bursts, low memory limits can cause OOMKills before logs flush. - Set requests to avoid eviction and limits high enough for the polling loop + infra launches. Useful docs roundup - Kubernetes worker how-to - Worker healthchecks - Self-hosted (Server) guide - All Prefect settings Next steps If you can share: - Worker logs around the restart - Worker Deployment/Helm values for env/probes - Your 
PREFECT_API_URL
and whether you use Ingress/TLS - Any NetworkPolicies between worker and server namespaces - Approximate run burst size and current work pool concurrency …I can tailor exact values (timeouts, probes, concurrency, resource requests) and provide a drop-in manifest/values.yaml tuned for your scale.
j
@Marvin this is my worker logs, which is deployed via helm. I do not have any concurrency configured 204537.066 | INFO | prefect.flow_runs.worker - Worker 'KubernetesWorker 77f7e3ee-eb83-4662-862c-0ae6612a9846' submitting flow run 'e2c09297-6bdb-4a14-b88c-30c043a6332c' 204537.067 | INFO | prefect.flow_runs.worker - Worker 'KubernetesWorker 77f7e3ee-eb83-4662-862c-0ae6612a9846' submitting flow run '5236bc26-c913-4871-9892-90eef4980cfb' 204537.068 | INFO | prefect.flow_runs.worker - Worker 'KubernetesWorker 77f7e3ee-eb83-4662-862c-0ae6612a9846' submitting flow run '2c936027-fb09-4d0a-a1f9-ac5855a073d1' 204539.627 | WARNING | kopf._core.reactor.queueing - Unprocessed streams left for [(pods.v1, 'bc535f49-c239-4ed8-bdc7-b929f9210f2c'), (pods.v1, '086d43ca-925d-4454-9f61-328417b07063'), (pods.v1, 'f58e084c-042e-46c6-aefc-32d40a7e62e2'), (pods.v1, '789efacb-8f14-4b9e-989d-386e892152d7'), (pods.v1, '9633bcab-0c74-4513-8d92-cd9ce6e305e9'), (pods.v1, 'b7c7e514-dc64-42ce-9b2f-1ece8b7148f1'), (pods.v1, '312bab0a-cdbf-4f5a-8504-c29fb87d9371'), (pods.v1, 'f06f300c-31c4-4b6f-988c-546803a16a8b'), (pods.v1, 'becc16b3-4cf6-42fc-99ab-5273a0c74caa'), (pods.v1, '75cf8d52-7ca7-4c26-b426-af09a0c5732a'), (pods.v1, 'd346a151-2085-4b28-b5e3-43499ed5cbf4'), (pods.v1, 'ff5b5722-b623-458e-92a0-2bf15cfd8fa7'), (pods.v1, '8300951c-7a86-4937-aaf2-93d6b4059950'), (pods.v1, '63430c5c-451b-4006-a174-ba6060345666'), (pods.v1, 'a0476df3-f86f-4c8b-866b-6e1cf92d7895'), (pods.v1, '3d2af1ed-f589-43a0-b97d-bf4e57a1def1'), (pods.v1, 'f20988ae-685d-4238-b3d7-4fb769fc4718'), (pods.v1, 'a7908e5f-0abd-466c-b289-e969051018d0'), (pods.v1, 'd07dbd84-4817-4f77-9329-ce707a9da989'), (pods.v1, '2fccf4d3-d6b6-483e-88a0-a41f833c9e76')]. 204539.628 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.629 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.630 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.630 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.632 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.633 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.633 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.634 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.634 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.635 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.635 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.635 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.636 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.636 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.637 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.637 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.637 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.638 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.638 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. 204539.639 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/prefect/cli/_utilities.py", line 44, in wrapper return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/cli/_types.py", line 156, in sync_fn return asyncio.run(async_fn(*args, **kwargs)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/asyncio/runners.py", line 190, in run return runner.run(main) ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run return self._loop.run_until_complete(task) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete return future.result() ^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/cli/worker.py", line 169, in start await worker.start( File "/usr/local/lib/python3.11/site-packages/prefect/workers/base.py", line 634, in start async with self as worker: File "/usr/local/lib/python3.11/site-packages/prefect_kubernetes/worker.py", line 938, in aexit await super().__aexit__(*exc_info) File "/usr/local/lib/python3.11/site-packages/prefect/workers/base.py", line 1578, in aexit raise exceptions[0] from None File "/usr/local/lib/python3.11/site-packages/prefect/workers/base.py", line 1222, in _submit_run await self.client.read_deployment(getattr(flow_run, "deployment_id")) File "/usr/local/lib/python3.11/site-packages/prefect/client/orchestration/_deployments/client.py", line 841, in read_deployment response = await self.request( ^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/client/orchestration/base.py", line 53, in request return await self._client.send(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/client/base.py", line 361, in send response.raise_for_status() File "/usr/local/lib/python3.11/site-packages/prefect/client/base.py", line 162, in raise_for_status raise PrefectHTTPStatusError.from_httpx_error(exc) from exc.cause prefect.exceptions.PrefectHTTPStatusError: Server error '500 Internal Server Error' for url 'http://prefect-server.prefect.svc.cluster.local:4200/api/deployments/37a36818-c460-4e67-abe5-4d45f443b12a' Response: {'exception_message': 'Internal Server Error'} For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500 An exception occurred.
m
Your message was too long, here's your message at the allowed limit: this is my worker logs which is deployed via helm I do not have any concurrency configured 20 45 37 066 | INFO | prefect flow_runs worker - Worker 'KubernetesWorker 77f7e3ee-eb83-4662-862c-0ae6612a9846' submitting flow run 'e2c09297-6bdb-4a14-b88c-30c043a6332c' 20 45 37 067 | INFO | prefect flow_runs worker - Worker 'KubernetesWorker 77f7e3ee-eb83-4662-862c-0ae6612a9846' submitting flow run '5236bc26-c913-4871-9892-90eef4980cfb' 20 45 37 068 | INFO | prefect flow_runs worker - Worker 'KubernetesWorker 77f7e3ee-eb83-4662-862c-0ae6612a9846' submitting flow run '2c936027-fb09-4d0a-a1f9-ac5855a073d1' 20 45 39 627 | WARNING | kopf _core reactor queueing - Unprocessed streams left for [(pods v1 'bc535f49-c239-4ed8-bdc7-b929f9210f2c') (pods v1 '086d43ca-925d-4454-9f61-328417b07063') (pods v1 'f58e084c-042e-46c6-aefc-32d40a7e62e2') (pods v1 '789efacb-8f14-4b9e-989d-386e892152d7') (pods v1 '9633bcab-0c74-4513-8d92-cd9ce6e305e9') (pods v1 'b7c7e514-dc64-42ce-9b2f-1ece8b7148f1') (pods v1 '312bab0a-cdbf-4f5a-8504-c29fb87d9371') (pods v1 'f06f300c-31c4-4b6f-988c-546803a16a8b') (pods v1 'becc16b3-4cf6-42fc-99ab-5273a0c74caa') (pods v1 '75cf8d52-7ca7-4c26-b426-af09a0c5732a') (pods v1 'd346a151-2085-4b28-b5e3-43499ed5cbf4') (pods v1 'ff5b5722-b623-458e-92a0-2bf15cfd8fa7') (pods v1 '8300951c-7a86-4937-aaf2-93d6b4059950') (pods v1 '63430c5c-451b-4006-a174-ba6060345666') (pods v1 'a0476df3-f86f-4c8b-866b-6e1cf92d7895') (pods v1 '3d2af1ed-f589-43a0-b97d-bf4e57a1def1') (pods v1 'f20988ae-685d-4238-b3d7-4fb769fc4718') (pods v1 'a7908e5f-0abd-466c-b289-e969051018d0') (pods v1 'd07dbd84-4817-4f77-9329-ce707a9da989') (pods v1 '2fccf4d3-d6b6-483e-88a0-a41f833c9e76')] 20 45 39 628 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 629 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 630 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 630 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 632 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 633 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 633 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 634 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 634 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 635 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 635 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 635 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 636 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 636 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 637 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 637 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 637 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 638 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 638 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate 20 45 39 639 | WARNING | kopf objects - Handler '_replicate_pod_event' is cancelled Will escalate Traceback (most recent call last) File /usr/local/lib/python3 11/site-packages/prefect/cli/_utilities py line 44 in wrapper return fn(*args *kwargs) ^^^^^^^^^^^^^^^^^^^ File /usr/local/lib/python3 11/site-packages/prefect/cli/_types py line 156 in sync_fn return asyncio run(async_fn(*args *kwargs)) ^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File /usr/local/lib/python3 11/asyncio/runners
j
@Marvin this is my stacktrace from worker, which is configured using helm 204539.639 | WARNING | kopf.objects - Handler '_replicate_pod_event' is cancelled. Will escalate. Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/prefect/cli/_utilities.py", line 44, in wrapper return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/cli/_types.py", line 156, in sync_fn return asyncio.run(async_fn(*args, **kwargs)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/asyncio/runners.py", line 190, in run return runner.run(main) ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run return self._loop.run_until_complete(task) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete return future.result() ^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/cli/worker.py", line 169, in start await worker.start( File "/usr/local/lib/python3.11/site-packages/prefect/workers/base.py", line 634, in start async with self as worker: File "/usr/local/lib/python3.11/site-packages/prefect_kubernetes/worker.py", line 938, in aexit await super().__aexit__(*exc_info) File "/usr/local/lib/python3.11/site-packages/prefect/workers/base.py", line 1578, in aexit raise exceptions[0] from None File "/usr/local/lib/python3.11/site-packages/prefect/workers/base.py", line 1222, in _submit_run await self.client.read_deployment(getattr(flow_run, "deployment_id")) File "/usr/local/lib/python3.11/site-packages/prefect/client/orchestration/_deployments/client.py", line 841, in read_deployment response = await self.request( ^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/client/orchestration/base.py", line 53, in request return await self._client.send(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/prefect/client/base.py", line 361, in send response.raise_for_status() File "/usr/local/lib/python3.11/site-packages/prefect/client/base.py", line 162, in raise_for_status raise PrefectHTTPStatusError.from_httpx_error(exc) from exc.cause prefect.exceptions.PrefectHTTPStatusError: Server error '500 Internal Server Error' for url 'http://prefect-server.prefect.svc.cluster.local:4200/api/deployments/37a36818-c460-4e67-abe5-4d45f443b12a' Response: {'exception_message': 'Internal Server Error'}
m
✅ thought for 237.5 seconds
Thanks for sharing the stacktrace — this is very helpful. What it means - The worker is failing while submitting a run because the Server API call to read the deployment returns a 500 Internal Server Error: - GET /api/deployments/37a36818-c460-4e67-abe5-4d45f443b12a → 500 - The 
kopf
warning you see is a side-effect of the worker shutting down due to that error; the root problem is on the Prefect Server side (not the worker networking). Most likely causes for a 500 on read_deployment - Server overload during a surge of runs (CPU/memory starved API pod) - Postgres issues (statement timeouts, connection pool saturation, slow queries on large tables) - A problematic/corrupted deployment record that triggers a serialization or DB error when read - Version mismatch between your workers/SDK and Server (less common but possible) Immediate next steps to isolate 1) Check the Server pod logs at the exact time of the 500 to see the stacktrace
Copy code
# Find server pod
kubectl get pods -n <server-namespace> -l <http://app.kubernetes.io/name=prefect-server|app.kubernetes.io/name=prefect-server>

# Tail logs around the failure time
kubectl logs -n <server-namespace> <prefect-server-pod-name> --tail=200 -f
This should show the exception that produced the 500 (e.g., DB timeout, validation error, etc.). If you can paste that here, I can pinpoint the fix. 2) Verify the deployment is readable outside the worker - Try fetching it directly from inside the cluster:
Copy code
curl -sS -v <http://prefect-server.prefect.svc.cluster.local:4200/api/deployments/37a36818-c460-4e67-abe5-4d45f443b12a>
- From your workstation/CI:
Copy code
prefect deployment inspect "<flow-name>/<deployment-name>"
If the CLI also fails, it confirms a server-side issue with that deployment endpoint. 3) If the 500 is only for some deployments - Recreate the problematic deployment and test: - Re-deploy with 
flow.from_source(...).deploy(...)
to a new name, then schedule a run to see if the worker can read it. - If a specific record is broken, this is a fast unblock. Stabilization steps for load spikes - Put a concurrency limit on your work pool to stop thundering herds while you investigate:
Copy code
prefect work-pool set-concurrency-limit "my-work-pool" 50
- Run multiple server replicas and give the API pod more resources. - Ensure Postgres is sized properly and healthy. If you see DB timeouts in server logs, increase the server’s database timeout and consider PgBouncer. If your DB is large, consider retention and routine VACUUM/ANALYZE. - Increase SDK request timeout on workers during load:
Copy code
PREFECT_API_REQUEST_TIMEOUT=120
Harden worker pods to avoid crashloops on transient hiccups - Start workers with healthchecks and probe the local endpoint:
Copy code
args:
  - prefect
  - worker
  - start
  - -p
  - my-work-pool
  - --with-healthcheck
env:
  - name: PREFECT_API_URL
    value: <http://prefect-server.prefect.svc.cluster.local:4200/api>
  - name: PREFECT_API_REQUEST_TIMEOUT
    value: "120"
  - name: PREFECT_LOGGING_LEVEL
    value: DEBUG
ports:
  - name: health
    containerPort: 8080
livenessProbe:
  httpGet: { path: /health, port: health }
  initialDelaySeconds: 60
readinessProbe:
  httpGet: { path: /health, port: health }
  initialDelaySeconds: 30
startupProbe:
  httpGet: { path: /health, port: health }
  periodSeconds: 10
  failureThreshold: 18
This prevents restarts when the API briefly struggles. Helpful docs - Worker healthchecks: Worker healthchecks - Kubernetes worker guide: Kubernetes worker how-to - Self-hosted Server and Helm: Self-hosted guide, Server Helm - Settings reference: Settings reference - Work pools: Work pools To help further, could you share:
- The server pod log stacktrace around 20:45 showing why the API returned 500 - Prefect versions (Server and worker image tags) - Whether this 500 happens for all deployments or only some - Postgres details (managed service vs in-cluster, CPU/memory, any errors) With that, I can recommend exact env vars/timeouts and, if needed, a values.yaml snippet for your Helm deployment.
42 Views
Open in Slack
PreviousNext
Powered by