You might see your hotspot labeled Offline or Inactive on some platforms. Since the Light Hotspot upgrade and the move to Solana, these labels are not protocol-level statuses anymore. They are UI interpretations based on recent activity and rewards, not a direct "online/offline" flag on-chain.
Original Helium L1 era (pre-2022)
Hotspots acted as full nodes on Helium's L1, synchronized the chain, and participated in the peer-to-peer network.
During this period, "sync gap," "relayed," and port-forwarding guidance (NAT rules for inbound connections) were
common troubleshooting concepts.
2022: Light Hotspots
Helium moved to Light Hotspots. Hotspots stopped following the blockchain and no longer relied on the
peer-to-peer network. As a result, "relayed" and "syncing" disappeared, and inbound port configuration became
unnecessary. Read the announcement
2023: Migration to Solana (completed April 18, 2023)
Helium moved its L1 to Solana. Hotspots are represented as NFTs, and most PoC and data-transfer processing is
handled by off-chain Oracles. On-chain data now focuses on rewards and key state, while detailed PoC receipts live
off-chain. Read the migration blog
All IoT hotspots are now "light." They do not sync a chain and they do not participate in a peer-to-peer gossip network. Instead, they connect to the network using gRPC and the Oracles handle PoC coordination. Because of this, there is no protocol-defined "offline" or "relayed" status anymore. Most apps infer status from recent PoC activity or rewards, not from a direct connectivity signal.
In the current architecture, hotspots submit PoC receipts to an Off-Chain PoC Oracle and forward device data to an Off-Chain Data Oracle. The detailed PoC receipts live off-chain, while on-chain state focuses on rewards and ownership. In Helium docs, all IoT hotspots are simply called "Hotspots" now because they are all light by default.
For example, the on-chain view includes a "rewarded in the last 30 days" signal (30 epochs since epochs are 24 hours). This is a rewards-activity indicator, not a real-time connectivity or "offline/online" state like the old full-node era.
Focus on activity and RF health rather than an "offline" label. A practical checklist:
Hotspots self-beacon on a target interval of about 6 hours with random timing ("jitter"), so you should see at least one beacon in each 6-hour window (the interval can change as the system evolves). If there are no recent beacon reports, start with the basics: stable power, a reliable Internet connection, and outbound connectivity (no inbound port forwarding is required).
A beacon report indicates the hotspot has power and Internet connectivity at the time of that report. The next check is whether those beacons are being witnessed. A healthy beacon is witnessed by nearby hotspots. If beacons are present but repeatedly show zero witnesses or are invalid due to "no valid witnesses," focus on RF chain issues: antenna quality, cabling loss, connector type, placement (outdoor and high), obstructions, or local hotspot density. In very sparse areas, few or no witnesses can be normal - but you should still optimize antenna placement. Occasional invalid beacons can be normal, but consistent invalids usually point to a real issue. If your setup is good and nearby hotspots should hear you, a faulty LoRa module is possible - contact your maker for repair or replacement guidance.
Check whether your hotspot is witnessing other beacons. If you are not witnessing at all, the same RF and placement issues above are likely. If you witness others but your beacons are not witnessed, it can indicate a transmit-side issue. If you beacon but never witness others, it can indicate a receive-side issue. Frequent late or invalid witness reports can also indicate weak signal, poor antenna performance, or a noisy RF environment.
If you expect device traffic, check data transfer receipts. Lack of rewards does not always mean the hotspot is "offline," and receiving rewards does not guarantee that all parts of PoC are healthy.
Some platforms, such as HeliumGeek, provide detailed PoC analytics such as last/invalid beacons, late/invalid witnesses, their timelines, and rewards. Use those views to confirm whether the hotspot is producing valid activity and to pinpoint when issues started.