Troubleshoot Device Tunnel CLI issues
Troubleshooting common issues with Device Tunnel and following best practices
Use this reference to diagnose and resolve common Device Tunnel CLI issues and follow best practices. Each entry includes the error symptom, root cause, and resolution steps.
Troubleshooting guide
| Issue | Symptom | Cause | Resolution |
|---|---|---|---|
| Orchestrator not running | Error: Device Tunnel Orchestrator is not running. | Orchestrator process is not running or status file is stale | 1. Check process: ./binary-macos-arm64 device-tunnel status2. Start it: ./binary-macos-arm64 device-tunnel start --username <user> --access-key <key>3. If status shows running but connect fails, run stop then start
|
| Orchestrator already running | Orchestrator is already running! PID: 12345 Port: 8080 | Orchestrator instance already active | Run ./binary-macos-arm64 device-tunnel stop then ./binary-macos-arm64 device-tunnel start --username <user> --access-key <key>
|
| Device not found | Error: Device ID “UNKNOWN123” not found in your dedicated devices. | • Typo in UDID • Device not in dedicated fleet • Device allocated to another user |
Run ./binary-macos-arm64 device-tunnel devices to list devices. Wait for device status to become available or contact support |
| Device name ambiguity | Error: Device “Pixel 7 Pro-13.0” exists on multiple platforms: android, ios. | Same device name exists on both platforms | Add --platform android or --platform ios flag: ./binary-macos-arm64 device-tunnel connect --device-name "Pixel 7 Pro-13.0" --platform android
|
| Tunnel stuck in PENDING | TUNNEL REQUEST ACCEPTED (PENDING) and no active tunnel after several minutes | • Network connectivity issue • Firewall blocking port 8080 • Orchestrator killed after API call |
1. Verify port 8080 is open 2. Check orchestrator: ./binary-macos-arm64 device-tunnel status3. Retry: ./binary-macos-arm64 device-tunnel connect --device-id <UDID> --new-connection4. Check orchestrator logs |
| ADB device not showing (Android) | connect succeeds but adb devices doesn’t show device | ADB not connected to tunnel port | Manually connect: adb connect localhost:<localPort> then verify with adb devices. If fails: ensure adb in $PATH, kill existing server: adb kill-server && adb start-server, check port binding: lsof -i :<localPort>
|
| Authentication failures (401) | Error: Authentication failed. Check your username and access key. | Invalid credentials | 1. Verify at profile page 2. Check for whitespace in environment variables 3. Verify browserstack_username and browserstack_accesskey in config file |
| Access denied (403) | Error: Access denied. Your account may not have Device Tunnel access. | Account lacks Bridge Cloud subscription | Contact BrowserStack support |
| BrowserStack Local conflict | BrowserStack Local instances are already running! | Existing BrowserStack Local process detected | 1. Kill processes: pkill BrowserStackLocal2. Or disconnect from dashboard 3. Retry start
|
| Multiple sessions for device | Error: Multiple running sessions found for “Galaxy S24-14.0”. | Multiple active sessions with same device name | Use --device-id instead of device name. Run devices to identify UDID |
| Partial multi-device failure | Some devices connect, others fail. Non-zero exit code | Device-specific connection issues | 1. Check stderr for error messages2. Re-run connect for failed devices3. Verify failed devices are available
|
| Request timeout | Error: Request timed out after waiting for device allocation. | • Device not in available state • 2-hour session limit reached • Device in cleanup phase |
1. Check device status is “available” 2. Wait 10 to 15 minutes for cleanup to complete 3. Retry on different device 4. Contact support if device stuck in cleanup |
A device also enters the cleanup phase when you manually stop a tunnel with the stop command, or when an error occurs mid-tunnel, not only when the 2-hour maximum duration for a continuous device block is reached. This behavior is consistent with real device sessions on App Automate. Cleanup typically takes 10 to 15 minutes. Before you retry a tunnel connection, verify the device shows available in the devices output, and contact BrowserStack support if a device goes offline or stays stuck in cleanup for longer than that.
Best practices
Follow these best practices to get the most out of Device Tunnel CLI.
Device identification
Always use --device-id over --device-name when you know the UDID. It is deterministic, enables auto-reconnect, and avoids ambiguity errors.
Session management
- Use
disconnectbetween test phases, notstop, if you want to preserve device state. The session and device allocation stay alive across disconnect and connect cycles. - Use
stoponly when fully done with a device. It frees the device back to the pool, which may make it unavailable if another user picks it up. - Use
--new-connectionsparingly. Creating a new session adds latency from build, session provisioning, and polling. Only use it when you genuinely need a fresh device state.
Monitoring and testing
- Monitor with
list-tunnelsin CI to verify tunnels are live before running tests:
- For parallel test suites, pre-connect all devices at the start of the suite, run all tests, then disconnect all at the end, instead of connecting or disconnecting per test.
Orchestrator management
Keep the orchestrator running for the entire test session. Stopping the orchestrator terminates all tunnels and cleans up all sessions.
Session duration
For sessions longer than 3 to 4 hours, be aware of potential hardware overheating on the physical device. Consider breaking long runs into shorter segments with device resets between.
Logging and diagnostics
Capture logs explicitly. This is a direct-access solution. BrowserStack does not automatically store logs, video, or network traffic. Use your own tooling to capture these.
CI/CD integration
Use --json in CI pipelines to parse results reliably without depending on text formatting.
Error codes reference
When using --json mode, errors include a code field for programmatic handling. Use these codes to implement retry logic or specific error handling in your automation.
| Error Code | Description | Common Causes | Resolution |
|---|---|---|---|
AUTH_FAILED |
Authentication failed | Invalid username or access key, no credentials stored on the orchestrator | Verify your username and access key in your config file or environment variables |
ACCESS_DENIED |
Account lacks the required subscription | Account doesn’t have a Bridge Cloud or Device Tunnel subscription | Contact BrowserStack support to verify your account permissions |
NOT_FOUND |
Device, session, or resource not found | Invalid device ID, session already stopped, device not in your dedicated fleet | Verify the device ID with the devices command, and check session status with sessions
|
CONFLICT |
Resource already exists | A tunnel is already active for the device | Run list-tunnels to check existing tunnels before retrying |
RATE_LIMITED |
Too many API requests | Excessive command or API call frequency | Wait before retrying, and reduce request frequency in CI scripts |
SERVICE_UNAVAILABLE |
BrowserStack service unavailable | API downtime, 5xx response, maintenance window | Retry after a delay, and check the BrowserStack status page |
NETWORK_TIMEOUT |
Operation timed out | Device provisioning timeout, network latency, slow response | Retry the operation, and check your network connectivity |
NETWORK_ERROR |
General network failure | Connectivity issue between your machine and BrowserStack | Check your network connection and firewall settings, then retry |
INVALID_ARGS |
Invalid command argument or flag | Malformed device ID, both --device-id and --device-name provided, ambiguous --device-name across platforms |
Verify command syntax, and check for mutually exclusive or missing flags |
UNKNOWN_COMMAND |
Command not recognized | Typo in the command name or an unsupported command | Run device-tunnel --help to see the list of supported commands |
PARTIAL_FAILURE |
Some devices succeeded, some failed in a multi-device operation | Mixed success and failure in a batch connect, disconnect, or stop operation |
Check the failed array in the JSON response for device-specific errors |
UNEXPECTED |
Unhandled exception | Orchestrator not running, or an unanticipated internal error | Run status to confirm the orchestrator is running, then check logs and retry |
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
Thank you for your valuable feedback!