Syself runs the platform under your clusters, and a support case reaches the team that operates it. A case is not always the fastest fix. Syself Autopilot replaces failed nodes on its own, and many problems are a setting you own and can change. The quickest resolution is often one you find yourself, so it is worth a short look before you write.
Email [support@syself.com](mailto:support@syself.com). Trials use the same address. Dedicated customers reach us in the shared Slack channel set up with their account; if you are unsure which channel applies, your primary contact at Syself confirms it. Your plan and the severity you agree on with support together set how quickly someone responds: see [support channels and SLAs](/docs/hetzner/apalla/support/channels-and-slas).
## Find it yourself first
The fastest fix is often one you already have. Press to search every page from anywhere, or take one of these paths.
The FAQ answers the questions that come up most: [getting access and starting](/docs/hetzner/apalla/support/faq#how-do-i-get-access-and-start), [how billing works](/docs/hetzner/apalla/support/faq#how-is-billing-calculated), and [how upgrades run](/docs/hetzner/apalla/support/faq#how-do-upgrades-work-is-there-downtime).
Match the symptom, or the exact error on a Cluster or Machine, to the runbook that owns the fix. Check self-healing first: a failed node may already be on its way out.
## When to open a case
Open a case when the self-serve paths run out:
- You have worked the runbook and the object is still unhealthy.
- The control plane or etcd is at risk, or data could be lost.
- The fix has to happen on the sealed node OS or a bare-metal server, which only Syself can reach.
## Write a first message we can act on
We solve a case by reconstructing what happened: what broke, when it started, and what you did around it. The more of that path you give us up front, the sooner the first reply works the real problem instead of asking for the basics.
Tell us what you saw and what you did, not a theory about the cause. Tools that guess at a root cause, AI assistants included, tend to invent cause and effect that does not hold for the cases that reach us, and a confident wrong theory sends the first reply chasing it. If you ran the problem through an assistant, leave its conclusions out, or label them clearly as a guess, and give us the raw observations underneath.
Keep the first message short and focused on the problem itself. Include:
- **So we can locate your cluster and verify the request:** your company name and the affected cluster's name and namespace. Write from your company email address, so we can confirm the request is yours.
- **So we can reconstruct the problem:** what is broken, since when, the exact error, and what you changed or ran just before and after it started.
- **If a node is involved:** attach the log-collector bundle, the `.zip` it produces, so we can read that node's logs directly. See [collect logs with the log collector](/docs/hetzner/apalla/support/collect-logs-with-the-log-collector).
- **If you have it:** the signal from your observability stack that shows the problem, a metric, a log line, or a trace. Helpful, but not needed to open the case.
The full checklist, with everything worth gathering, is on [what to collect first](/docs/hetzner/apalla/support/what-to-collect-first). When the fix has to happen on a bare-metal server, see [grant Syself bare-metal access](/docs/hetzner/apalla/support/grant-syself-baremetal-access).
Adding users, setting roles, and granting cluster access are self-service. See [add users](/docs/hetzner/apalla/platform/add-users), [roles and permissions](/docs/hetzner/apalla/platform/roles-and-permissions), and [manage access and tenancy](/docs/hetzner/apalla/security/manage-access-and-tenancy).