Troubleshooting

Check the device LED now

Use the LED to understand what the device is doing right now:

• LED Off: likely power issue (or device not booted).
• Blinking Green: attempting to connect to the network and cloud but currently unable to establish a connection.
• Blinking Blue: application running, but not connected to the network.
• Solid Green / Solid Blue: device is connected now; offline state in cloud may be stale or intermittent.
• Blinking Yellow: update in progress; wait until update finishes.

For full LED definitions, see LED status indicators.

Check last known signal quality before offline

In PRIZM Cloud, open Device page → Device Action → See logs. At the top of the logs view, review the latest signal quality around the offline timestamp, then inspect:

• $SYS/device/status and $SYS/device/status_number
• $SYS/device/quality and $SYS/device/quality_number

Interpretation:

• Status = Updating (2) or Updating Firmware (3) right before offline may indicate a disconnect during update activity.
• Status = Running (4) before offline confirms application activity was healthy before connectivity dropped.
• Quality = Poor (1) before offline usually means RF/network coverage instability.
• Quality = Medium (2) suggests intermittent network conditions.
• Quality = Good (3) before offline can still drop to offline during heavy data bursts. Quality reflects end-to-end delivery health (device link + server processing time), not only raw cellular/Wi-Fi signal strength.

For field details, see System Device Fields.

If this happened right after deploying a Blueprint

A device going briefly Offline while a Blueprint is being deployed is expected — it reconnects on its own once the application finishes applying. While this is happening, a small icon appears next to the device.

If quality shows Poor, use this quick recovery checklist

1. Check placement and signal path
   • Reposition the device or antenna away from metal enclosures and electrical noise sources.
   • If on cellular, move to a location with better coverage if possible.
2. Reduce data load temporarily
   • Lower publish frequency.
   • Batch or reduce payload size.
   • Avoid sending large bursts until connection stabilizes.
3. Validate network path
   • Confirm router/AP uplink stability and internet reachability.
   • Check firewall/DNS changes that may block cloud traffic.
4. Watch logs for trend
   • Keep the logs open and confirm quality improves from Poor to Medium/Good before returning to normal traffic volume.

Use this quick diagnosis

Information to include before escalating

When opening a support ticket, include:

• Device ID
• Time window when offline happened (with timezone)
• LED state observed during incident
• Last $SYS/device/quality / $SYS/device/quality_number before disconnect
• Whether the device recovered automatically or required intervention

Check device logs for the crash message

Open Device page → Device Action → See logs and filter by ERROR. A crash is typically logged as:

Application crashed at <location> with message: <message>

The <location> indicates where the panic occurred in the Blueprint runtime, and <message> describes the cause. Use this to identify the offending node or input.

Review the Blueprint for panic-prone inputs

If the crash repeats after restart, the Blueprint logic is likely producing values that trigger a runtime panic. Common causes:

• Invalid references — a node referencing data that does not exist (missing field, unbound input).
• Type mismatches — an input arriving with a type the node was not configured to handle.

Open the Blueprint editor and review the inputs and references for nodes that handle dynamic data.

Restart the Blueprint application

In PRIZM Cloud, open the Device page and click Action → Restart App. This relaunches the Blueprint without rebooting the device. If the crash was caused by a transient runtime condition, the application may recover after a restart.

Reboot the device if the application still won’t run

If Restart App does not recover the device, use Action → Reboot Device to perform a full device restart. This clears any leftover runtime state before the Blueprint runs again.

Roll back to a previous Blueprint version

If the crash started right after a recent deploy and the cause is not yet clear, redeploy the previous working version of the Blueprint. This restores the device to a known-good state while you investigate the new version.

Information to include before escalating

If you have tried all the troubleshooting steps above and the issue still persists, please submit a request through the Feedback form.

When submitting the request, include:

• Device ID
• Time the App Crashed state first appeared (with timezone)
• The Blueprint version currently deployed, and the previous version if it was just changed
• The full error line from device logs (Application crashed at ...)
• Whether Restart App, Reboot Device, or a rollback was attempted, and the result

Click Settings

Navigate to the main menu and click on Settings.

Click Data & Integrations

Select the Data & Integrations tab from the top or side menu.

Copy Company ID

Locate the Company ID field and click to copy the key to your clipboard.

Check whether Location Tracking is on for its bundle

Location Tracking is a per-bundle setting, and a device with no bundle can’t have it at all — see A registered device does nothing until it is in a bundle. Open the device’s bundle and confirm Location Tracking is turned on. See Location Tracking.

Check the device’s connection status

Resolving a location is a network operation, so a device that is Offline can’t resolve one no matter what interval is set. Bring the device back online first — see Device appears offline in Cloud Console.

Wait out the interval

Turning on Location Tracking doesn’t backfill a location — it resolves on the schedule you picked from that point on. On the longer presets, 3d and 7d, the first location can take days to appear. If you need to see one sooner, temporarily switch the bundle to a shorter interval.

Check the widget’s field selection

A Map widget only plots whichever Latitude/Longitude/Radius Field you picked in its configuration. If your blueprint reports its own GPS fields, the widget may be pointed at those instead of the system fields Location Tracking writes to — $SYS/device/location/latitude, longitude, radius. Point the widget at whichever fields you actually expect data on.

Check your credit limit

Location Tracking spends credits on every resolve, and stops like everything else once your company reaches Max Credits. If every device’s location stopped updating at once, check Settings → Billing before anything above.

Force a hard refresh

A hard refresh bypasses your browser’s local cache and forces it to download the most recent version of the page.

• Windows / Linux: Press Ctrl + F5 or Ctrl + ⇧ + R.
• Mac: Press ⌘ + ⇧ + R.

Clear your browser cache and cookies

If a hard refresh doesn’t resolve the issue, clear your browsing data according to your browser:

• Google Chrome / Microsoft Edge

  • Press Ctrl + ⇧ + Del (Windows/Linux) or ⌘ + ⇧ + ⌫ (Mac) to directly open the clear data menu.
  • Select Cached images and files and Cookies and other site data.
  • Click Clear data (or Clear now in Edge).

• Mozilla Firefox

  • Press Ctrl + ⇧ + Del (Windows/Linux) or ⌘ + ⇧ + ⌫ (Mac) to open the “Clear recent history” window.
  • Ensure Cookies and Cache are selected.
  • Click Clear Now.

• Apple Safari (Mac)

  • Press ⌘ + , to open Settings, then navigate to the Privacy tab.
  • Click Manage Website Data… and click Remove All.
  • (Alternatively, to clear history and website data together, go to the top menu bar: History > Clear History…)

Once the data is cleared, close your browser entirely, reopen it, and log back into PRIZM Cloud.

Check for interfering browser extensions

Certain extensions—especially Ad-blockers, aggressive tracking protection, or VPNs—can block the background scripts required by PRIZM Cloud to maintain a live connection.

• Temporarily disable your extensions one by one, refreshing the page each time to identify the culprit.
• Once identified, whitelist the PRIZM Cloud URL in that extension’s settings.

Open the widget’s settings

Click Start Editing on the dashboard and open the widget’s settings. A bundle that no longer exists shows in red as Deleted bundle, and a device that no longer exists or is no longer in the selected bundle shows in red as Missing device. The widget can still be saved with a missing value.

Check whether the bundle still exists

Open Bundles. If the bundle the widget points to is gone, deleting it is what caused the warning — see Deleting a bundle.

Check whether the device is still in that bundle

A device belongs to one bundle at a time, so moving it to another bundle takes it out of the old one — see One bundle per device. Also confirm the device itself hasn’t been deleted.

Choose a bundle or device that still exists

Pick a current bundle and device in the widget’s settings. If they are gone for good, remove the widget. The widget does not retry on its own, so refreshing the dashboard won’t clear the error until the setting is fixed.

Create at least one bundle

Go to Bundles and create a bundle — see Create a bundle. A bundle takes only a name, and a single device is a valid bundle of one.

Return to the Blueprint Editor

Ship becomes clickable once a bundle exists, even an empty one.

Add the target device(s) to that bundle

See Add a device to a bundle so the deployed application actually has somewhere to run.