SUPPORT PATH
This guide provides a fixed troubleshooting sequence covering first connection, builds, and performance. Confirm the local network, target address, credentials, and node status before checking tools or resource metrics. This avoids repeated guesswork and helps support reproduce the issue faster.
FIND THE PATH
Enter an error message, connection method, system task, or node status. Search only matches visible documentation on this page; your input is not uploaded.
Showing 7 support paths
Confirm that the node is ready, the credentials come from the correct source, and the local network can reach it. Then calibrate the keyboard layout and time zone.
Estimated time: 3–5 minutes Connection issuesIsolate the local network, target address, credentials, node status, and client settings in that order.
Run the 5-layer check in order Build tasksPin the tool versions first, then check signing materials, dependency caches, free disk space, and task logs.
Keep the complete command and timestamps Performance diagnosticsRecord CPU, memory, disk, and network metrics while the issue occurs instead of submitting a single momentary screenshot.
Sample continuously for 5–10 minutes Ticket escalationClassify the request as an account issue, unreachable node, hardware issue, or data request, and attach the minimum relevant evidence.
Use console tickets for existing orders Status assessmentUse same-region comparisons, cross-network tests, and console status to clearly describe the scope of impact.
Determine the scope before escalating Evidence preparationGather the node ID, time range, exact error text, reproduction steps, and redacted logs to reduce follow-up requests.
Do not submit passwords, private keys, or project source codeTry keeping only the key terms from the error, or select “All.” If the issue concerns an existing order, submit a console ticket with the exact error text.
Open the console to submit a ticketFIRST SESSION
Do not change multiple connection parameters at once. Record the result after each step so you can tell whether the issue is local, network-related, authentication-related, or on the node.
In the console, check that the target node is marked ready and verify its node ID, region, and selected model. If the node is still preparing, do not use a client error alone to diagnose a connection failure.
Completion criteria: The node ID matches the order and the status allows connections.Copy the address, port, and username from the current node details in the console. Do not use records from old tickets, screenshots, or another node. When pasting the password, watch for leading or trailing spaces and full-width characters from the input method.
Completion criteria: The address, port, and username come from the same node details.First confirm that ordinary HTTPS access works, then test the office network and a trusted backup network separately. A corporate gateway, firewall, or proxy may block only specific ports, so being able to open a web page does not guarantee remote connectivity.
Completion criteria: Record the network used, egress type, and failure time.After entering the macOS graphical interface, test letters, numbers, symbols, and Command and Option mappings. If symbol positions differ, record both the local keyboard layout and the selected remote layout.
Completion criteria: The terminal can accurately enter quotation marks, slashes, and hyphens in commands.Mark the time zone consistently in task logs, CI records, and tickets. When investigating intermittent errors, “14:20” without a time zone cannot be matched to node events. Use a complete date and time with the time zone.
Completion criteria: Times in local, node, and automation logs can be converted to one another.DECISION TREE
Connection timeouts usually point to the network or address; authentication failures usually point to the username, password, key, or client configuration. Route by error type first, then run the five-layer check.
Disable temporary proxies that change routing and retry, then run one comparison using a trusted backup network. If the office network fails but the backup network works, record the egress policy and affected ports; the issue should first go to your local network administrator.
Continue when:A connection attempt to the same target has been completed on at least one trusted network.
Return to the console and copy the target information again; do not reuse an address from command history. For browser remote desktop, use the entry provided by the console. For SSH, verify that the host, port, and username belong to the same connection record.
Stop when:The address has changed or the record belongs to another node; update it and test again.
Check username capitalization, spaces around the password, key-file permissions, and the selected identity file. When an SSH host fingerprint appears for the first time, compare it with the console information. If the fingerprint changes unexpectedly, pause the connection and confirm the reason through a ticket.
Evidence requirement:Keep the exact error text, but redact the password, key contents, and complete access address.
Refresh the node details and confirm the status, node ID, and last change time. If the status is abnormal, do not repeatedly perform restart-like actions. Record the pre-action status, actions taken, and time of each action so the incident state is not overwritten.
Escalate when:The node status is abnormal, or the status is normal but the node is unreachable from both trusted networks.
If the browser page is blank, retry with the current stable browser after clearing this site's session data. If the keyboard is misaligned, switch to a single layout. If SSH sessions disconnect frequently, disable terminal extensions first and establish a comparison session using basic commands.
Completion criteria:Record the client name, version, connection method, and reproducible steps.
Submit the network types, failure time, target region, comparison results from both networks, and the node status in the console. Do not submit only a screenshot without a time or node ID.
First verify the current node's username, authentication method, and client identity file. In the ticket, include only the authentication method and exact error text; never send passwords, private keys, or directly usable credentials.
BUILD PIPELINE
Start with the first clear failure, not the summary on the final line. Pin the toolchain first, then check signing, dependencies, disk space, and automation processes.
Record the macOS version, Xcode version, command-line tools path, and build command. If the graphical interface and automation task use different tool paths, they may produce different results on the same node.
Distinguish missing certificates, mismatched provisioning profiles, incorrect authorization scope, and keychain access failures. For diagnostics, keep the certificate name, validity period, and error text, but redact certificate files, passwords, and sensitive project identifiers.
First determine whether the failure can be reproduced reliably with the lockfile, then clear the smallest possible cache scope. Deleting all dependencies and build caches at once adds variables and may temporarily hide the original issue.
Archives, dependency extraction, and temporary artifacts need extra space. Checking only the project directory size is not enough; also check available capacity, temporary directories, build caches, and whether the automation process was terminated for insufficient resources.
PERFORMANCE SAMPLE
A single CPU screenshot cannot explain disk wait, memory pressure, or network fluctuations. Sample continuously for 5–10 minutes before and after the issue, and mark when the task starts and fails.
| Metric | Record at least | What to watch for | Compare with the task |
|---|---|---|---|
| CPU | Total utilization, main processes, sampling time | One process consuming resources continuously, a sudden load spike, or utilization that does not fall after the task ends | Mark the start of compilation, linking, testing, or inference |
| Memory | Used memory, memory pressure, swap space | Sustained pressure, frequent swapping, or processes terminated by the system | Record the number of parallel tasks and input size |
| Disk | Free space, read/write throughput, I/O wait | Space nearly exhausted, or noticeable waits during extraction or archiving | Distinguish dependency downloads, build-cache activity, and artifact writes |
| Network | Local network type, round-trip latency, packet loss | Only one egress path is affected, or interaction is sluggish while the node task remains normal | Distinguish remote display, dependency downloads, and code fetches |
Record a baseline before the task starts and continue until at least one minute after the issue. Data from only the moment of failure cannot show whether resource changes caused the issue or resulted from it.
Record one successful task with the same project, dependencies, and parallelism. Compare the stages and resource curves, not just total duration.
If the remote display stutters but the node task duration is stable, check the network first. If the task itself takes longer, continue with CPU, memory, and disk checks.
MINIMUM EVIDENCE
You do not need to upload the entire project for a support request. The fields below are usually enough for an initial assessment; support will request more if anything is missing.
Node ID, node region, macOS version, and Xcode or client version. Do not enter passwords, private keys, or complete access credentials.
Use “date + hours:minutes:seconds + time zone” and mark the first occurrence, last occurrence, and most recent reproduction.
Copy searchable text instead of uploading only a screenshot. Keep the error code, failure stage, and log context before and after the first error.
Start from a known-good state and list the actions, commands, expected result, and actual result in order. Include the reproduction rate.
List the time and result of switching networks, updating the address, clearing caches, or restarting the task to avoid repeating actions that overwrite the incident state.
ESCALATION RULES
Describe one primary issue per ticket. If account access and a node failure occur together, create separate records so their handling statuses do not overwrite each other.
| Category | When to use | Recommended evidence | Preferred channel |
|---|---|---|---|
| Account issue | Cannot access the console, or account details or access verification are failing | Registration email, occurrence time, exact page error, browser version | Support email |
| Unreachable node | The node allows connections, but neither browser remote desktop nor SSH can establish a session | Node ID, region, results from two network tests, error time and exact text | Console ticket |
| Hardware issue | Repeated unexpected restarts, storage errors, or resource anomalies that a single task cannot explain | Node ID, system-log time range, task before the issue, reproduction frequency | Console ticket |
| Data-related request | Node release, data-export process, or privacy-rights request | Order ID, request scope, desired action, and necessary identity-verification information | Console ticket |
The node status allows connections, but browser remote desktop and SSH are both unreachable after testing two trusted networks. Submit the node ID, region, and time of the most recent successful connection.
The node is reachable, but a build or automation task consistently fails with a pinned toolchain. Submit the first error, complete command, exit code, and shortest reproduction flow.
The node is usable, but the issue involves keyboard layout, resolution, dependency caches, or workflow optimization. Describe the current configuration, desired result, and solutions already tested.
SERVICE CONTINUITY
All nodes are designed to operate normally 365 days a year with continuous availability. When an issue occurs, distinguish a regional network fluctuation, single-node failure, or local connection issue by its scope.
Multiple connection sources in the same area show higher latency, packet loss, or session interruptions at around the same time, while tasks inside the node may continue running.
The local network and other services in the same region work normally, but the target node has an abnormal status, repeatedly goes offline, or shows system errors that the user's task cannot explain.
The target node works from a backup network or another client; only one office egress, browser configuration, or SSH client fails.
“Node SG-example has been unable to connect via SSH since 2026-08-08 14:20 +0800; both home and office networks time out, while the console still shows the node as allowing connections.”
Do not write only “the server is broken,” “the network is slow,” or “it disconnects sometimes.” Without the node, time, network source, and exact error text, the scope of impact cannot be determined.
QUICK ANSWERS
First confirm the node ID and status in the console, then recopy the address, port, and username from the current node details. Next, run one comparison using a trusted backup network. Do not perform multiple node-state-changing actions before recording the status.
Prioritize at least 50 lines before and after the first error, the complete build command, exit code, Xcode version, and occurrence time. Redact project paths, repository addresses, or signing information from complete logs before submitting. Do not remove error codes or timestamps.
A screenshot shows only one moment and cannot establish whether a resource change happened before or after the task. Continuously record CPU, memory, disk, and network metrics for 5–10 minutes, marking task start, issue, and end times.
Prioritize console tickets for existing orders, nodes, hardware, and data-related requests so they can be linked to order and node records. For account issues where you cannot access the console, email support@macworker.com. These are the only two contact channels available.
Do not submit passwords, private keys, payment credentials, complete access addresses, or project source code. You may redact sensitive values in logs, but retain field names, versions, error codes, timestamps, and call order.
READY TO ESCALATE
Link the existing order through a console ticket and submit the shortest reproduction steps with redacted logs. If you have not rented a node yet, open the portal to choose an exclusive physical machine configuration, region, and term.