Einführung
If a device is showing offline in Level but is actually powered on and connected, the cause is almost always AV/EDR interference or a firewall blocking the agent's outbound connections. Start with the --check command — it identifies the exact failure point without guesswork.
ℹ️ NOTE: In most cases, Level works without any firewall changes. The network requirements below only apply if you're on a restrictive network and actively experiencing connectivity problems.
Offline Troubleshooting
Step 1: Run the Diagnostic Check
Run --check on the affected device while it has network access. It tests every part of the agent's connectivity to Level and reports exactly where the failure is.
🖥️ PLATFORM NOTE:
Windows:
& 'C:\Program Files\Level\level.exe' --checkmacOS:
sudo /usr/local/bin/level --checkLinux:
sudo /usr/local/bin/level --check
The two sections to focus on:
Level checks — shows whether the agent service and watchdog task are in the expected state (Running / Ready). If either shows a problem, AV/EDR has most likely quarantined the agent binary. The watchdog keeps the service running under normal conditions — if it's not, something external stopped it.
Connection checks — shows the status of online.level.io, agents.level.io, uptime monitor, and realtime client. Any failure here points to a blocked network path.
Step 2: AV/EDR Interference
If --check shows the service or watchdog not in the expected state, or if --check won't run at all, check whether the Level binary is still present on disk:
🖥️ PLATFORM NOTE:
Windows: look for
level.exeinC:\Program Files\Level\macOS: look for
levelat/Applications/Level.app/Contents/MacOS/levelLinux: look for
levelat/usr/local/bin/level
If the binary is missing, AV/EDR removed it. Level has no mechanism to delete its own binary — a missing executable means your security software quarantined or deleted it.
To investigate: Check your security software's quarantine log and activity history around the time the device went offline. Look for any action taken against level.exe or related processes. Some products — SentinelOne, ESET, and certain Defender configurations — do this silently with no visible alert.
To fix: Restore the binary from quarantine if possible, then add the appropriate exclusions before reinstalling. See AV/EDR False Detections for exclusion paths, certificate details, and a Windows Defender automation you can deploy across devices. If the binary is still present but the service is stopped, the same exclusion steps apply — the AV is likely blocking execution rather than removing the file.
⚠️ WARNING: If you reinstall the agent without adding exclusions first, AV/EDR will remove the binary again. Add exclusions before reinstalling. Also note: AV/EDR detections against Level are behavior-based, not signature-based. This means the same security software can run on 50 devices and only flag Level on a few — it depends on what the agent was doing at the time the detection was triggered, not on a definition update. Don't assume a clean device means your exclusions are working correctly.
Step 3: Check Network Access
If the Level checks section looks healthy but Connection checks show failures, the agent is running but can't reach Level's servers. The issue is a firewall or proxy blocking outbound connections.
The agent needs outbound access to these URLs:
URL | Purpose |
| Agent communication with Level |
| Connectivity status checks |
| Agent updates |
| Initial agent installation |
| Real-time WebSocket for Level API |
| File storage for automations |
| TURN relay (used when P2P fails) |
| STUN (used when P2P fails) |
| Log collection for troubleshooting |
💡 TIP: For firewalls that support wildcard rules, *.level.io and *.twilio.com cover the Level and Twilio entries above.
Required ports (outbound only):
Port | Protocol | Purpose | Notes |
80 | TCP | HTTP | Basic connectivity |
443 | TCP | HTTPS | Primary agent traffic |
3478 | TCP & UDP | TURN | Used when P2P fails |
5349 | TCP | TURN TLS | Last-resort fallback only |
10,000–60,000 | UDP | TURN relay ports | Allocated by Twilio when TURN is used |
ℹ️ NOTE: Ports 3478, 5349, and the UDP range are only needed when P2P connections can't be established. Start with 80 and 443 — that covers the vast majority of scenarios. See Relay/P2P Troubleshooting if remote connections specifically are failing.
Step 4: Contact Support
If --check doesn't point to a clear cause, contact Level Support with:
The full output from
--checkAV/EDR software in use (name and version)
Any firewall or proxy software between the device and the internet
Häufig gestellte Fragen
The device was online yesterday and just went offline. Where do I start? Run
--checkfirst. If it won't run at all, check whetherlevel.exe(Windows) or thelevelbinary (macOS/Linux) is still present on disk — if it's gone, AV/EDR removed it. If the binary is there but--checkshows the service stopped or connection check failures, see AV/EDR False Detections for the quarantine log investigation and exclusion steps.I don't have any way to access the device remotely right now. What can I do? If Level is your only remote access tool on the device, you'll need physical or out-of-band access (iDRAC, iLO, KVM, etc.) to investigate. Once you have access, run
--checkto identify the cause before doing anything else.Do I need to open all these ports in my firewall? Not unless you're experiencing problems. Most networks work with just 80 and 443 outbound. The TURN ports (3478, 5349) and UDP range are only relevant if P2P connections are failing — see Relay/P2P Troubleshooting before opening additional ports.
The --check output looks fine but the device is still showing offline in Level. The console can lag a minute or two after connectivity is restored. If it doesn't update, the issue may be intermittent — try running
--checkagain when the offline status recurs to catch the failure in the act.