Start with the symptoms below. For help with an instance, billing or a node, sign in to the console and submit a ticket. Haven’t rented a Mac yet? You can explore the available plans first.
Support is available by console ticket or email. Report urgent issues through a ticket and mark them as urgent—there’s no need to look for another contact channel.
Use a ticket for SSH connection failures, instance issues, renewals, payment checks or anything that may require us to review node-side records. Include the instance ID, when the issue started, its impact and the checks you’ve already tried.
First response targetWithin 4 hours for high-priority tickets; within 1 business day for standard requests.
Get in touch if you haven’t rented an instance yet, need to check hardware compatibility or have questions about team purchasing. Email support@zshmac.com with your use case, estimated number of machines, preferred node and rental period.
First response targetReply within business hours. For issues with an existing instance, submit a ticket and include its ID.
If the instance is completely unreachable, multiple connection methods fail, or you suspect a node-level incident, create a console ticket and select urgent priority. Don’t repeatedly reinstall while the state of your data is unclear.
First response targetWithin 1 hour for urgent tickets. Include the last time you could access the instance normally.
Response times are targets, not guarantees that an issue will be fixed within that time. Instance details in a ticket help us investigate more than repeated emails.
All available nodes run year-round, 365 days a year. Availability is measured by calendar month. If you experience a connection outage, include the time period, instance ID and symptoms in your ticket so we can check the node-side records.
If monthly availability falls below 99.9%, account credit is calculated based on the duration of the outage. Submit a request through a console ticket within 7 days after the end of the month. Events beyond our reasonable control and issues caused by user actions are excluded from service-side downtime.
This is an illustrative target, not a record of past uptime. For actual incidents and their impact over the last 90 days, check service announcements and ticket records in the console.
Work through the checks in order, and note when the issue occurred and the exact error message. If you need help, add your findings to the same ticket so you don’t have to repeat the initial checks.
| Symptom | Suggested checks and details to include |
|---|---|
| SSH connection times out | First, check the instance status and current connection address in the console. Then test port reachability from your local network and check your VPN, proxy and firewall rules. If the port is reachable but authentication fails, verify the username, key permissions and any recent credential changes. Include the connection time, your outbound network and the full error message in your ticket. |
| VNC black screen or wrong resolution | Check whether SSH still works to distinguish a desktop session issue from a full instance outage. Reconnect to screen sharing and check the client’s resolution and colour settings. If the screen is still black, note the client type, when it started and whether you can run commands over SSH. Don’t reinstall macOS as a first step. |
| Xcode certificate or provisioning profile error | Check the selected Xcode version, build target and signing settings. Verify the certificate’s expiry date, that the keychain is unlocked, and that the provisioning profile matches the app ID and device scope. For CI, also confirm that the runner account can access the required keychain. Attach redacted build logs to your ticket; never share private keys. |
| Not enough disk space | Run df -h to check available volume space, then review DerivedData, simulator devices, archives and container images. Before deleting anything, check whether it’s needed for build caching or delivery records. If your workload keeps growing, see our storage upgrades and Mac plans. |
| Self-hosted runner is offline | Check that the instance is online and can reach your code hosting service. Then check the runner process, service account permissions, registration token and job queue. If only builds are failing, keep the job logs and exit code. If the instance is also unreachable, submit a ticket using the SSH connection steps above. |
These steps are for troubleshooting only and won’t change your instance. Don’t share connection credentials, certificate private keys or full payment details on public pages.
Both actions are available from your instance details after you sign in. Decide whether you need to keep the current system state before proceeding.
Open the instance in the console, verify its model and node, and make sure no builds, uploads or file writes are in progress. Then restart it. This will interrupt SSH and VNC connections, as well as running tasks. Once the system is back up, reconnect and check your services.
Restart time depends on the system’s shutdown state and current workload. If the instance doesn’t come back up, note when you restarted it and submit a ticket.
Back up your code, certificates, configuration files and build artefacts outside the instance first. Then confirm the instance in the console and proceed with reinstalling macOS. Reinstallation erases the instance, so you’ll need to set up your environment, caches and local configuration again.
Reinstallation time depends on the system installation and provisioning process. Follow the progress and final credentials shown in the console; don’t submit the action more than once.
Before renewing, check the instance, rental period and billing details. If you plan to release it, back up your data elsewhere and stop any pipelines that depend on the machine. Its disk will be erased after release, so don’t use the instance as long-term backup storage. To check release status or billing records, sign in to the console and submit a ticket.
These topics point to further reading, not support tickets. For personal instance logs, billing changes or node incident checks, sign in to the console.
Set up your SSH key, command-line tools and screen sharing, then check that you can connect to the desktop.
Read the getting started guidePinpoint issues with toolchain versions, DerivedData caches, build settings or runner services, and keep logs for reproducible jobs.
Browse technical articlesCheck keychain access, certificate expiry and provisioning profile matches. Remove sensitive details before sharing logs.
Browse technical articlesWhen running containers and builds together, keep an eye on unified memory, disk space and background processes.
Browse technical articlesStart by checking the unified memory required by your model and context window, then choose a suitable Mac and rental period.
Compare Mac plansUpdate your existing ticket with the latest impact, when you first reported the issue and any new evidence. Make clear that you haven’t received an initial response yet. Keeping everything in one ticket preserves the troubleshooting context; please don’t create multiple tickets for the same issue.
If you suspect a node-level incident, check service announcements after signing in to the console, then follow up on your ticket to confirm whether your instance was affected. Announcements cover shared incidents; instance recovery and service credit reviews are handled through your ticket.
Follow the getting started guide from placing your order and receiving connection credentials through to your first build. For pre-sales advice, email our team.