Setup-time issues (TLS, SSH, webhooks, authentication redirects) are covered in setup troubleshooting. This page covers the failures that show up in day-2 operation, and which log answers each one.
Each service logs to its own container. Three you will read most:
sfp server logs --tenant my-app --tail 200 # server + standard workers
docker logs <tenant>-hatchet-worker-longrunning-1 --tail 200 # long-running workers
docker logs <project>-hatchet-engine-1 --tail 200 # task-queue engineThe health endpoint (GET https://<your-domain>/sfp/api) reports per-component status and the count of active workflows — check it before and after any intervention.
The server does not come up after a start or reboot. sfp server status shows which service is down or restarting. Read that service's container logs first. A database container that is unhealthy blocks everything downstream — resolve it before looking at the application server. A container in a restart loop usually names its reason in the first lines after each restart.
A workflow run is stuck or appears hung. Open the run in the Runs view and check whether steps are still progressing. Long-running steps against Salesforce (package version creation, org provisioning) are governed by Salesforce's processing time and can legitimately run for tens of minutes. Compare against the previous run of the same workflow before concluding it is stuck. If steps are genuinely not progressing, read the worker logs for the run id.
Workers behave as if they are running old code after an update. Confirm every container is on the same image tag: docker ps --format '{{.Names}} {{.Image}}'. The application server and the workers share one image; if any worker shows an older tag, re-run sfp server update and verify again. A mixed-version stack produces inconsistent behaviour that looks like a product bug.
No metrics or logs arriving in your observability backend. Covered in monitoring — collector configuration, authentication headers, and endpoints.
Anything that requires changing database contents, editing files inside containers, or applying a patch by hand is not a self-service operation — capture the run id, the relevant log excerpt, and the output of sfp server status, and contact flxbl support. The same applies when a failure persists across a restart and an update with no cause visible in the logs.
Last updated
Was this helpful?
Was this helpful?