Engineering support hub
This hub covers connection, system, build, network, storage, and account issues on cloud Macs. Complete the basic checks in order, then record the node, incident time, and redacted logs to reduce back-and-forth.
Issue routing
Do not change multiple variables at once. In each round, adjust only one of the connection method, client settings, build parameters, or network path, and keep the before-and-after results.
Rejected credentials, unreachable ports, display issues, input lag, or dropped sessions.
Open connection checksThe graphical session, permissions, disk mounts, time settings, or process status do not match expectations.
Check system statusThe Runner is offline, the queue is blocked, the dependency cache is invalid, the signing environment is incorrect, or packaging fails.
Open build checksPacket loss, jitter, DNS resolution failures, route changes, or unstable upload and download performance.
Open the diagnostics workbenchCapacity planning, expansion SSD detection, cache cleanup, backups, and migration before the rental term ends.
Check storage and dataOrder IDs, access credentials, billing records, payment results, or console actions need verification.
Prepare a support requestRemote connection troubleshooting
First confirm that the connection target is correct, then check the port and client. Do not use repeated credential resets to mask network- or session-layer issues.
Copy the current instance hostname, port, and username from the console, and make sure you are not using details from an old order. Check the keyboard layout, capitalization, leading and trailing spaces, and password-manager autofill. Do not include passwords, private keys, or a complete connection string in screenshots or the ticket body.
Use nc in your local terminal to check the specified port. A successful TCP connection only confirms that the port is reachable; it does not mean the graphical session is working. If the request times out, continue recording your local network, carrier, and target node.
nc -vz "$TARGET_HOST" "$TARGET_PORT"Confirm that the instance is running, the graphical-session service is available, and the current account has permission for remote sessions. If the command line connects but the display does not, narrow the issue to the graphical service, client negotiation, or a stale session instead of changing network settings again.
Establish a baseline with one display, lower resolution, and lower image quality, then restore scaling, color quality, and multi-display settings one at a time. If low resolution is stable but high resolution stutters, also collect latency, packet loss, and client encoding settings.
Exit the client normally, wait for the old connection to be released, and establish the session again. Avoid connecting multiple clients to the same graphical session. If the interruption recurs, record the exact minute, client version, whether you changed networks, and whether the command-line connection was affected at the same time.
CI/CD troubleshooting
Start with a minimal job that does not read project secrets or install dependencies. Once it passes, add the repository, cache, signing materials, and archive steps layer by layer.
Verify that the Runner is registered to the correct project or organization, its labels match, and its executor is online. If a job remains queued, check labels and concurrency limits first, then inspect the Runner process instead of rerunning the entire pipeline.
ps aux | grep -i runner
launchctl list | grep -i runnerConfirm that the account used by the build process, keychain search paths, certificate visibility, and provisioning-profile scope are consistent. Keep only certificate names, the failure stage, and error text in logs; remove passwords, private-key contents, and complete signing materials before submission.
security list-keychains
security find-identity -v -p codesigningKeep dependency caches, derived data, and final artifacts in separate directories. When cache hits behave unexpectedly, record the cache key and directory usage, then clean only the affected project instead of deleting every working directory and losing comparison data.
du -sh "$CACHE_PATH"
df -h
find "$CACHE_PATH" -maxdepth 1 -type dRecord when queuing began, execution started, and execution ended. Distinguish between “the job was not picked up” and “the job started but produced no output for a long time.” For the former, focus on labels, concurrency, and Runner status; for the latter, check waiting scripts, network dependencies, and child processes.
Keep at least 50 log lines before and after the failed step, along with the command exit code, tool versions, and the smallest reproducible set of publicly shareable project parameters. Do not submit only an error-dialog screenshot, and do not upload a complete log bundle containing tokens, repository credentials, or business data.
xcodebuild -version
sw_vers
uname -mAfter the first failure, save the original logs before retrying once with the same commit and parameters. If the retry succeeds, compare network requests, cache hits, and execution time. If it fails consistently, narrow the issue to a single command and record its inputs, exit code, and duration.
Network diagnostics workbench
A single ping does not represent link quality. Collect one set of results while the issue is occurring and another after recovery, keeping the local network, target address, and command parameters consistent.
Send 20 consecutive packets and save the minimum, average, and maximum latency and packet-loss rate.
ping -c 20 "$TARGET_HOST"Use the route results to identify which hop begins showing latency changes. Some routers do not respond to probes; that alone does not mean the link is down.
traceroute "$TARGET_HOST"Record the resolution result, response time, and DNS servers currently in use to distinguish resolution issues from target-port issues.
dig "$TARGET_HOST"
scutil --dnsUse the built-in macOS tool to collect upload and download capacity, responsiveness, and idle latency. Pause large-file synchronization and other high-bandwidth tasks during the test.
networkQuality -vStorage and data handling
Storage issues are rarely about a single capacity figure. Define directory boundaries, write permissions, recoverable copies, and migration timing before the first build.
After adding expanded storage, first check that the system detects the device, the volume is mounted, and the file system is writable before changing build directories. Do not switch cache or artifact paths while a job is running.
diskutil list
df -h
mountService availability
Status records help determine the scope of any service-side impact. The service terms govern the specific measurement window, exclusions, eligibility requirements, service credits, and applicable scope.
Nodes operate normally 365 days a year. Impacts caused by force majeure, user actions, user-side networks, or workload configuration are excluded from platform availability.
If you believe an order was affected by a platform-side service event, retain the order ID, node, first-detected time, recovery time, and continuous probe records, then submit them through a console ticket. Eligibility for and the form of any service credit are governed by the specific service-term rules.
View service termsSubmit a support request
Organize each technical support request around one issue. Describe different nodes, orders, or failure stages separately to prevent timelines from overlapping.
Provide the order or instance ID shown in the console. Do not send account passwords.
Specify Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong.
Include the date, time zone, start time, duration, and whether the issue has recovered.
State separately what you expected to happen and what you actually saw; do not write only “it doesn’t work.”
List the shortest path from the normal state to the failure, and state whether retries reproduce it consistently.
Include logs before and after the failed step, command exit codes, and necessary screenshots. Remove tokens, passwords, private keys, payment credentials, and business data.
Keep error codes, timestamps, command names, tool versions, path structures, and exit codes. Replace access tokens, passwords, private keys, credentials in repository URLs, real user names, and business data. After redaction, search again for common secret prefixes and email addresses.
Include at least one continuous ping set, one traceroute, the incident time, target node, local city and carrier, and whether the result changed after switching to wired, Wi-Fi, or a mobile hotspot.
Usually not. Start with the failed command, exit code, logs before and after the failure, tool versions, and minimal reproduction steps. If a sample is required, remove business code, keys, signing materials, and production data, keeping only the smallest structure that reproduces the issue.
Get ready to submit
For existing-order issues, use a console ticket first; for general inquiries, contact support by email. Complete context lets engineers begin with an actionable sample.