Unable to connect
First confirm the device status, access method, local egress network, and system time. Then distinguish timeouts, permission denials, fingerprint changes, and interrupted graphical sessions.
View connection checksReproduce first, then escalate
Document the Cloud Mac environment while the issue is occurring
This guide does not route issues by department. Instead, it checks connection failures, build errors, disk space, performance fluctuations, billing, and node status step by step. After basic diagnostics are complete, your ticket can enter effective investigation immediately.
6
Issue categories
99.9%
Target uptime
6
Available nodes
Diagnostic ticket
Information to collect
Turn symptoms into verifiable records
Impact scope
Single task / single device / team-wide
Required timing
Time of occurrence, time zone, and most recent known-good time
Environment baseline
macOS, Xcode, commands, and exit codes
Security boundary
Submit redacted logs only; never submit complete secrets
With complete evidence, the support team can first determine whether the issue involves the node, device, system access, or project environment.
Choose by symptom
Select the entry point closest to your situation
Do not guess the cause first. Record the directly observed symptoms, impact scope, and order of occurrence, then follow the relevant diagnostic path. If one issue involves multiple symptoms, start with the earliest one.
Build failure
Keep the complete command, exit code, and first actionable error. Verify that Xcode, macOS, dependency lockfiles, and the project branch match the successful baseline.
Troubleshoot the buildDisk space
Check free space on the system volume, derived data, build caches, model files, and temporary artifacts. Do not look only at the project directory while overlooking system-volume pressure.
View storage diagnosticsPerformance fluctuation
Collect CPU, memory pressure, free disk space, and long-running task data together to determine whether the cause is a resource limit, task contention, or changed project input.
Run performance diagnosticsBilling issue
Prepare the order ID, billing period, and payment result from the console. Orders are settled in USD and support USDT-TRC20 and Visa / Mastercard / Amex (via Stripe).
View billing in the consoleNode status
First determine whether one device, one node, or multiple locations are affected, and record the actual node and most recent successful access time. Do not substitute a geographic location for the node name.
View the service-status definitionsPre-connection checks
Five basics—missing one can lead to a wrong diagnosis
Connection issues often result from status, credential scope, the local network, or time drift. Checking in order helps preserve the original state instead of overwriting it through repeated attempts.
-
01
Confirm the device status in the console
Verify the order ID, current node, and device status. Do not treat an old browser-cached screenshot as the current result; the console's live response is authoritative.
-
02
Confirm the account and access details belong to the same device
Check the host, user, and port individually when copying them to avoid mixing details from another device or an old session. State which details you used in the ticket, but do not paste complete secrets.
-
03
Confirm the access method matches the task
For command-line tasks, verify SSH first. When an Xcode graphical interface is required, verify remote desktop access separately. Record both results; do not use one failed test to represent the other.
-
04
Check the local egress network
Record the current network type and whether a proxy or corporate firewall is involved, then run one comparison test over another controlled network. Report only the test result, not the full internal network configuration.
-
05
Check local and remote system time
Significant time drift can affect certificates, signing, and access verification. Record the time zone and ensure the incident time in the ticket corresponds to the log timestamps.
Build troubleshooting
Find the first actionable error, then determine whether it is environmental or project-related
The failure summary at the end of build output is usually not the root cause. Save the complete log, locate the earliest clear error, and compare the same input with the most recent successful baseline.
Environment collection commands
Read-only checks
sw_vers
xcodebuild -version
git rev-parse --short HEAD
git status --short
df -h /
xcodebuild -scheme App -configuration ReleaseConfirm before running that the commands will not output secrets. If the project uses a dependency manager, also record the lockfile summary and installation-command result.
Unrelated projects fail simultaneously
If a minimal test project and the production project fail at the same stage, or system commands also behave abnormally, record the macOS and Xcode versions, free disk space, and complete exit code.
Only a specific branch or dependency combination fails
If a minimal project succeeds on the same device while the target branch fails after lockfile, build-parameter, or resource changes, review project changes first.
Versions, command, exit code, log excerpt
Submit the Xcode and macOS versions, dependency-lockfile summary, complete xcodebuild command, exit code, and redacted output surrounding the first actionable error.
1
Pin the branch and inputs
Do not continue updating dependencies or switching configurations during troubleshooting.
2
Save the complete output
Keep the original log separately and create a redacted copy before sharing it.
3
Run the smallest task
Use the smallest scheme or a test project to verify the environment baseline.
4
Compare with the latest successful record
Compare versions, parameters, cache state, and task inputs.
Performance and storage
Break “slow” down into CPU, memory, disk, and task duration
A longer single-run duration does not prove a device issue. At minimum, record the baseline duration for the same input, resource peaks, and concurrent tasks before deciding whether to clean up, scale up, or change configuration.
Sampling checklist
Four metric categories
Cross-check Activity Monitor with command-line data
CPU
Sustained usage, process names, and concurrent task count
top -l 1 -o cpu
Memory
Memory pressure, swap usage, and peak periods
memory_pressure
Disk
System-volume free space, cache, and artifact growth
df -h /
Long-running tasks
Start time, input size, and runtime
ps -axo pid,etime,command
HopVM M4 16
M4 · 16GB · 256GB
Suitable for single-project compilation, short tests, and low-concurrency automation. If memory pressure remains high, reduce concurrency first, then compare with HopVM M4 24.
HopVM M4 24
M4 · 24GB · 512GB
Suitable for running development tools, simulators, and automation tasks together. If large models or heavy builds continuously use swap, consider HopVM M4 Pro 64.
HopVM M4 Pro 64
M4 Pro · 64GB · 2TB
Suitable for large-model inference, heavy builds, and high-memory workflows. Before upgrading, record input size and peak usage to avoid mistaking network wait time for insufficient compute.
Clean up regenerable data first
Confirm whether derived data, old build artifacts, unused simulator data, and download caches can be regenerated. Before deleting anything, verify that the project does not depend on a unique local artifact.
Add storage when capacity keeps growing
If project source files are small but models, media assets, or build archives keep growing, consider the available +1TB SSD or +2TB SSD add-on.
Record peaks separately from the baseline
Record idle, normal-task, and peak-concurrency stages separately. Only sustained resource pressure supports an upgrade decision; investigate the triggering task first for occasional peaks.
Service uptime
99.9%
Target uptime
All nodes are designed to operate normally throughout 365 days of the year. Status is recorded daily for the past 90 days; the 30 segments below summarize results for every three calendar days.
90-day uptime summary
Green indicates normal operation; yellow marks events that have been closed and does not indicate a current issue.
Normal operation
Closed event
Measurement basis: daily status records for the past 90 days
What status records include
Records include node connectivity, device status, impact scope, start and recovery times, and the conclusion after an event is closed. A build error in a single project is not directly counted as node unavailability.
How to request compensation if the commitment is not met
Submit the order ID, actual node, issue time and time zone, impact scope, and connection evidence through the console. When eligible, request compensation with the evidence and within the time limit specified in the service terms.
Ticket evidence template
State all six details once to avoid back-and-forth questions
A ticket should allow someone who was not present to reproduce the issue using the same steps. Use the real order ID and node from the console; do not replace them with a device nickname or internal team abbreviation.
Recommended ticket structure
Copy and fill in
Order ID:
Actual node: SG / JP / KR / HK / US-E / US-W
Issue time and time zone:
Most recent successful time:
Impact scope:
Reproduction steps:
1.
2.
3.
Expected result:
Actual result:
Exit code or error type:
Redacted log excerpt:The six nodes are Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, US East, and US West. Keep only the node code actually used.
Order and node
Use the order ID to associate the device. Select the actual node from SG, JP, KR, HK, US-E, and US-W.
Time and time zone
State the first occurrence, most recent successful time, and time zone so status records can align with user logs.
Reproduction steps
Start from a known-good state and list the commands, inputs, and actions in order, without omitting key steps before the failure.
Expected vs. actual
Describe separately what should happen and what actually happened. Avoid writing only “it doesn't work” or “it's slow.”
Error and exit code
Prioritize the first actionable error, exit code, and stage of occurrence instead of copying only the final log line.
Redacted output
Preserve call relationships, timestamps, and error types; remove passwords, complete keys, tokens, payment credentials, and project secrets.
Response boundaries
The support team confirms the service boundary first, then provides next steps
Different issues require different evidence. Until the impact scope and environment checks are complete, we will not make unverifiable promises about a specific recovery time.
| Issue type | What HopVM can verify | What the user should provide | Assessment |
|---|---|---|---|
| Node connectivity | Node status, network reachability, impact scope, and status records | Actual node, source network, time and time zone, and comparison test | Distinguish a single egress, single-device, or node-level impact |
| Device status | Device operating status, resource-delivery records, and console association data | Order ID, most recent successful time, and number of affected tasks | Confirm whether device status matches the console result |
| System access | Access-detail scope, session entry point, and system-level connection symptoms | Redacted access method, error type, fingerprint, or permission result | Distinguish timeout, permission, time-drift, and local-network restrictions |
| Development tools | Help verify whether the device environment and system resources are functioning normally | Xcode, macOS, dependency versions, complete command, exit code, and minimal reproduction | Determine whether to investigate project dependencies or third-party tools |
| Billing and orders | Order status, billing period, payment result, and accounting records | Order ID, payment-method category, time of occurrence, and console result | Use the order and gateway status returned by the live console |
Can be verified directly
Node connectivity, device status, system access entry points, order association, and service-side status records.
Requires joint reproduction
Performance fluctuations, intermittent connections, failures at specific build stages, and issues occurring only with specific inputs.
Requires continued project-side handling
Third-party dependency defects, project-code errors, build-script logic, and unverified tool-compatibility issues.
Escalation entry point
Hand the diagnostic ticket to the support team after basic checks are complete
Submit existing order, connection, and device-status issues through the console so they can be linked to the actual resources. For urgent incidents, state the impact scope, actual node, issue time, and most recent successful time first.
If you cannot access the console, email support@hopvm.com and use this page's evidence template in the message, removing all secret values.