Get support
Syself operates the platform underneath your clusters. A support case goes to that same team. Before you open one, take a short look at the runbooks and the FAQ. Syself Autopilot replaces failed nodes on its own, so a problem you are watching may already be resolving itself. Plenty of others come down to a setting you own and can change.
Reach support
Email support@syself.com. Trials use the same address. Dedicated customers have a shared Slack channel set up with their account; if you are not sure which one applies, ask your primary contact at Syself. How quickly someone responds depends on your plan and on the severity you agree on with support. See support channels and SLAs .
Find it yourself first
Press Ctrl+ K to search every page from anywhere, or start with one of these.
The FAQ covers what comes up most often: getting access and starting , how billing works , and how upgrades run .
Match the symptom, or the exact error on a Cluster or Machine, to the runbook that covers it. Check self-healing first, since a failed node may already be getting replaced.
When to open a case
Open a case when the self-service paths run out:
- You have worked through 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 on 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 that time. Give us that up front and the first reply can get straight to the real problem. Without it, our first message back is just a request for the basics.
Theories about the cause
Tell us what you saw and what you did. Please leave out your theory about what caused it. If you ran the problem through an AI assistant, keep its conclusion out of the ticket, or label it clearly as a guess. These tools tend to invent cause and effect that doesn't hold for the cases that reach us, and a confident wrong theory sends our first reply chasing it. What we need underneath is the raw observation.
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. It produces a
.zipthat lets us read that node's logs directly. See 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. This is useful context, though you can open the case without it.
The full checklist, with everything worth gathering, is on what to collect first . When the fix has to happen on a bare-metal server, see grant Syself bare-metal access .
No case needed
Adding users, setting roles, and granting cluster access are self-service. See add users , roles and permissions , and manage access and tenancy .
Runtime threat detection
Deploy Falco or an equivalent to catch what the preventive controls miss, then wire it into a detect-and-respond loop for a compromised workload.
Where to start troubleshooting
Match a symptom to the runbook that owns it, read a Machine or Cluster event, and know when to stop and contact Syself.