First-time setup
Connection details not yet verified
For recently completed orders that need the model, node, host address, login method, and initial network state checked.
View setup checks
Developer task support
Preserve the evidence first, then trace the issue by task
Connection failures, build errors, and degraded performance usually have different causes. PingMini organizes troubleshooting across setup, access, toolchains, task execution, storage, and accounts—so every step has inputs, checks, and verifiable results.
- 6 entry points
- Choose a path for your current task
- 5 context items
- Order, node, time, error, and steps
- 2 contact channels
- Console ticket or support email
BUILD SUPPORT BOARD
Route the current task
Prepare to troubleshoot
ACCESS
Verify address and fingerprint
Network
XCODE
Pin the version and replay the build
Logs
RUNNER
Isolate the failed task directory
Task
STORAGE
Check space and cache growth
Capacity
Record when it happened and the last known good state
CASE READY
Choose an entry point
Start with the task in progress—not the error code
Choose the entry point closest to the current blocker. Each path lists the information to keep and the next action. If an issue spans multiple paths, start with the earliest abnormal step.
Remote connection
Session, network, or credential issue
For issues involving the graphical desktop, SSH, host fingerprints, connection timeouts, keyboard layouts, or clipboard policies.
Check the connection path
Development environment
Xcode and toolchain mismatch
For version switching, command-line tools, certificates and provisioning profiles, dependency caches, and build-log analysis.
Troubleshoot the toolchain
CI/CD
Self-hosted task execution failed
Check runner registration, working-directory permissions, keychain access, concurrency rules, and failed-task cleanup as one complete flow.
Check the task execution flow
Storage & performance
Storage is growing or tasks are slowing down
Separate the system disk, additional SSD, build cache, and project data so capacity issues are not mistaken for compute limitations.
Plan storage capacity
Account & orders
Order, renewal, or permissions need review
Prepare the order number, node code, time, and scope of the action, then submit a request through the console linked to the service status.
Prepare a support request
First-use path
Establish a reproducible starting point with four checks
Do not migrate a project, change the toolchain, and add automation during the first connection. First prove that the node, credentials, and network work, then add the development environment layer by layer.
-
01
Result: all fields captured
Get connection details
Open the relevant order in the console and record the host address, connection method, account name, and node code. Do not keep only a screenshot; put the order number and connection details in a team-controlled handoff record.
-
02
Result: configuration matches
Verify the node and model
Confirm that the node, chip, memory, and SSD in the order match the intended use. The three catalog configurations are M4 / 16GB / 256GB, M4 / 24GB / 512GB, and M4 Pro / 64GB / 2TB.
-
03
Result: re-login successful
Complete the first login and change credentials
Establish a minimal session first to confirm that the desktop or command line is accessible, then change the initial credentials. Sign out and reconnect immediately afterward to verify that the new credentials work.
-
04
Result: reproducible baseline
Verify the network and basic commands
Check DNS resolution, repository access, and dependency-source connectivity, then run a basic command that does not change system state. Record the local network, client, and failure time to distinguish later between link issues.
Xcode & toolchain
Break “build failed” into version, permissions, cache, and logs
When the same code behaves differently across environments, pin the toolchain inputs first. Do not upgrade Xcode and clear caches at the same time, then treat one lucky success as proof the issue is gone.
Recommended troubleshooting order
VERSION
Confirm the current Xcode and command-line tools
Version record
Record the graphical version, build number, and the actual command-line-tools path. The project, scripts, and CI should reference the same verifiable toolchain.
SIGNING
Check certificate and provisioning-profile boundaries
Permission scope
Verify that the files exist and permissions are correct, confirm that the CI account can access the required keychain, and record whether the failure occurs during parsing, archiving, or signing.
CACHE
Clear caches by layer
Single-variable retest
Clear project derived data first, then package-manager caches, and only afterward consider broader environment cleanup. Change one layer at a time and replay the same build.
LOG
Keep the first genuine error
Complete logs
Use the complete log to find the earliest failed step, command, target, and exit code. Do not copy only the final summary line.
Keep before submitting
View contact requirements
Minimal build evidence package
- Xcode and command-line-tools versions
- Project target and failed stage
- Full command, exit code, and log excerpt
- Difference from the last successful build
Avoid false conclusions
View workflow examples
Do not change the entire environment at once
If you upgrade versions, reinstall dependencies, delete caches, and replace signing materials simultaneously, even a recovered build cannot reveal the real cause. Change only one input per round.
CI/CD troubleshooting
Prove runner health first, then replay the failed task
Automation failures may come from registration state, the execution account, the working directory, the keychain, or concurrency contention. Check the task lifecycle instead of repeatedly registering the runner and hiding the root cause.
Confirm task registration
Check that the runner is online, its labels match, and the execution account is the expected one. If the task is not picked up, check queue rules and labels first; do not immediately reinstall the toolchain.
- Input
- Runner name, labels, and queue status
- Acceptance
- A minimal test task can be picked up
Verify directory and keychain permissions
Using the actual execution account, check read/write access to the working, cache, and artifact directories, then separately verify access to the keychain required for the build.
- Input
- Execution account, directory paths, and permission results
- Acceptance
- A minimal build completes without privilege escalation
Limit concurrency and clean up leftovers
Reduce concurrency to a controllable level and check leftover processes, lock files, temporary directories, and incomplete archives. After a failed task ends, define a cleanup strategy instead of continuing to occupy the environment.
- Input
- Concurrency, process list, and disk usage
- Acceptance
- Repeated replays produce consistent results
Registration healthy
Permissions clear
Single task passes
Restore concurrency gradually
SSH into a Mac
Verify keys, fingerprints, network, and permissions separately
A connection timeout and an authentication failure occur at different stages. First confirm that the host is reachable, then check the host fingerprint and key permissions, and finally verify a non-interactive command.
Minimal connection flow
Establish one clean session with explicit parameters
- Prepare the key:Create a dedicated key for the current purpose, restrict the private-key file permissions, and never copy the same private key among multiple people.
- Confirm the fingerprint:Before the first connection, verify the host address against trusted order information. If the fingerprint changes, stop connecting and investigate the reason.
- Check the timeout:Confirm the local network, egress policy, host address, and port. Do not mistake a timeout for an incorrect password.
- Tighten permissions:Use the minimum account permissions required to complete the task, and verify automation with a non-interactive command.
ssh -i ~/.ssh/pingmini_ed25519 user@host
ssh -i ~/.ssh/pingmini_ed25519 user@host "uname -a"
Connection timeout
Output: link conclusion
Check the reachability path
Record the local network, host address, port, time, and client error. Prove network reachability first, then handle authentication.
Authentication failed
Output: permission conclusion
Check the key and account
Verify the private key, target account, file permissions, and server-side authorization scope. Do not repeatedly try uncertain credentials.
Storage & performance
First identify which type of data is growing
The system disk, additional SSD, project data, and build cache have different lifecycles. Capacity planning must account for the current project, peak builds, archived artifacts, and migration space before the rental ends.
| Storage category | Best for | What to monitor | Recommended action |
|---|---|---|---|
| System disk | Operating system, toolchain, required apps, and core configuration | Free space, temporary files, and the number of toolchain versions | Do not accumulate archived artifacts long term; keep a safety buffer |
| Additional SSD | Large projects, assets, models, build artifacts, and team handoff data | Continuous write volume, per-project peaks, and migration time | Organize active and archived data in separate directories |
| Build cache | Derived data, dependency caches, and regenerable intermediate files | Hit rate, growth rate, and leftovers from failed tasks | Set cleanup rules; do not mix it with unique project data |
| Project data | Code, configuration, assets, test data, and final deliverables | Whether an independent copy exists, permission scope, and handoff owner | Create a project backup and pre-expiry migration checklist |
Record free space and daily growth
Record initial usage before importing the project, then record a typical workday's growth during normal operation. These figures help distinguish steady growth, burst archiving, and failed-task leftovers.
Keep inputs, intermediates, and artifacts together
Video transcoding, large archives, and model tests may retain source data, intermediate files, and outputs at the same time. Do not choose capacity based only on final artifact size.
Separate disk pressure from compute pressure
Record task duration, free space, concurrency, and cache state. Near-full storage, frequent cleanup, or multiple tasks competing for one directory can all make tasks appear slower.
Security response
When something looks wrong, narrow access first
Suspected credential exposure, unusual logins, team handoffs, and rental end are four different scenarios, but all should follow the sequence: stop spread, preserve records, rotate access, and verify cleanup.
Pause related access
Stop sharing credentials, end unnecessary sessions, and pause automation that could expand the impact. Do not broadly delete logs before recording the situation.
Record the incident context
Collect the order number, node, discovery time, source of the anomaly, affected accounts, and the last known good action. Keep necessary client and task logs.
Rotate credentials and keys
Replace affected login credentials, SSH keys, and automation access materials, and revoke permissions for team members who no longer need them. Do not change only one location and continue reusing old keys.
Verify and complete cleanup
Retest required access and confirm that old credentials no longer work. Before a handoff or rental end, migrate project data, build artifacts, keys, and certificates, then clean the node according to the checklist.
Escalate to support
Give every request enough information to enter troubleshooting directly
General questions and active service issues are handled according to impact and actionable context. The more complete the information, the fewer basic fields need to be confirmed back and forth.
Five items to include before submitting
Order number
Used to link the model, rental period, and service records.
Node code
Enter the one matching the order: SG, JP, KR, HK, or US-E.
Time of occurrence
Include the time zone and the time of the last known good action.
Error details
Keep the full text, exit code, and earliest failure point; do not submit only a cropped screenshot.
Reproduction steps
Start from a working state and write out the commands, inputs, expected results, and actual results step by step.
Active service issue
Sign in and submit a ticket
Use a console ticket first
For problems with an order, node, connection, or running task, a console ticket makes it easier to link the request to service records.
General inquiry
Send a support email
Use the standard support email
For product selection, team purchasing, billing, or partnership questions, email support@pingmini.com with your use case and desired outcome.
When a connection fails, should I submit a screenshot or a text error?
Prioritize copyable full error text, the client name, time, and steps taken. A screenshot can supplement the interface state, but cannot replace host-address verification, the exit code, or network-stage diagnosis.
If a build succeeds occasionally, does that mean the node is healthy again?
Not based on one success. Pin the Xcode version and replay continuously with the same commit, dependencies, and concurrency, recording the input differences between successful and failed runs.
When tasks slow down, should I upgrade the model immediately?
First record CPU, memory, free space, cache state, concurrency, and task stage. If the bottleneck is insufficient space, directory contention, or failed-task leftovers, changing the configuration alone will not remove the cause.
Next step
Prepare the context, then hand the issue to the support team
If you are still choosing a setup, review the three fixed configurations first. If the service is already active, submit a ticket with the order number, node, time, error details, and reproduction steps.