Reading Network Statistics in the Meshtastic App

Understanding what your Meshtastic network is actually doing requires knowing how to read the statistics the app surfaces. The mobile app (Android and iOS) and the web client all expose channel utilization, airtime, packet counters, and radio-level metrics. This page explains every number, what healthy ranges look like, and how to spot a congested network before it starts dropping messages.

Where to Find Network Statistics

Android App

Open the Meshtastic Android app and navigateopen toa node's Device Metrics (telemetry) view — tap a node in the node list, then open its Device Metrics / telemetry panel. Channel utilization and air-utilization metrics are shown there (the live stats live in the telemetry view, not in Settings → Radio Configuration → Device., Channelwhich utilization and airtime metrics appear atis the topconfiguration of the device status screen.editor). Individual node signal metrics (SNR and RSSI) are shown in the node list by tapping any node row and selecting Node Info.

iOS App

Tap the Nodes tab, then tap any node to see its detail card. Signal strength, last heard time, hop count, and telemetry battery readings are all shown here. The channel utilization percentage is displayed on the Mesh tab's header area when connected to a local node.

Web Client (meshtastic.local or IP)

On the web client served directly from the device, the Dashboard section shows live channel utilization, air utilization, and packet statistics. This is the most detailed view and updates roughlyperiodically everyas 15new seconds.telemetry arrives.

Channel Utilization %

Channel utilization measures what fraction of available airtime on the LoRa channel has been consumed by transmitted packetspackets, averaged over a rolling 1-minute window. The firmware computes it by summing on-air milliseconds across six 10-second sub-windows. (typicallyThis is a separate metric from the lastper-hour 5duty orcycle, 15which minutesis dependingthe onregulatory firmwareairtime version).percentage discussed below.)

Utilization Range	Network Health	Interpretation
0 - 15%25%	Healthy (green)	Plenty of spare capacity. All traffic should get through.
15This -is the firmware's green/throttle boundary — above ~25%	Moderate	Noticeable load.the Startfirmware auditingbegins positiondelaying broadcast intervals.transmissions.
25 - 50%	High (orange)	Collisions increasing. The firmware delays TX above ~25%; routers cut back telemetry around 40%. Expect occasional packet loss.
50 - 100%	Congested (red)	Severe contention. Most non-acked packets will be lost.

The underlying metric is computed by the device firmware using the LoRa modem's receive statistics. Every received or transmitted packet's on-air time is summed and divided by the window period. A single packet at SF10 / BW125 / CR 4/5 takes approximately 370 ms on air. At theThe default LongFast preset youuses canSF11/BW250/CR4/5; fita small (~50-byte) packet at this configuration takes roughly 40400–700 ms on air (the exact figure depends on payload size and preamble length). As an illustrative estimate, that means only a handful of such packets per minute beforewill hittingpush utilization toward 25% utilization -— a limit that islevel easily exceeded on a busy community mesh. (Note: SF11/BW250 LongFast is much slower than shorter presets — for example MediumFast at SF9 transmits roughly 3× faster than LongFast at SF11.)

Air Utilization

Air utilization is closely related but specifically counts the fraction of time the radio was actively transmitting (TX duty cycle). RegulatorsSome in many countriesregulators impose per-hour duty-cycle limits (e.g.,for 1%example or 10% duty cycle per hour inthe EU 868 MHz sub-bands).bands Meshtastic'shave firmware1% enforcesor these10% duty-cycle limits internally;under whenETSI EN 300 220). These per-hour duty-cycle limits apply to EU 868 MHz sub-bands. The US/Canada 902–928 MHz band (47 CFR 15.247 / ISED RSS-247) imposes no duty-cycle limit on digital-modulation LoRa systems — the limitgoverning limits there are conducted power (1 W / 30 dBm), EIRP, and frequency-hopping/dwell rules, not an airtime percentage. So in the US/Canada, watching air utilization is approachedabout avoiding mesh congestion, not staying under a legal airtime cap. Where a regional duty-cycle limit does apply, the devicefirmware will delay or drop outgoing packets to help stay compliant.compliant; Ifif you see the air utilization climbingclimbing, toward your regional limit, reducereducing your transmit frequency.frequency reduces congestion either way.

Packet Counters

The firmware maintains several packet counters that help diagnose forwarding behavior:

• Packets Rx: Total valid LoRa packets received (passed CRC check).
• Packets Rx Bad: Packets received with a failed CRC. A high ratio of bad packets to good packets indicates RF interference or a node with a damaged antenna.
• Packets Tx: Packets this node has transmitted (original or forwarded).
• Packets Tx Relay: Subset of Tx that were relayed on behalf of another node. A router node should have a high relay ratio. A client node with a very high relay count may be flooded because its hop limit is too generous.
• Packets Rx Duplicate: Packets seen more than once. Some duplication is normal in mesh (same packet arrives via multiple paths); more than 10 - 20% of total Rx suggests a routing loop or misconfigured hop limits.

SNR - Signal-to-Noise Ratio

SNR is the most important single-number indicator of link quality. It is reported in decibels (dB) and expresses how far above the noise floor the received signal sits. LoRa can decode packets at negative SNR values because spread-spectrum processing gain allows it to recover signal from noise. The decode floor is spreading-factor-dependent, so the bands below are rules of thumb that shift with your preset (see the note after the table).

SNR (dB)	Link Quality	Notes
≥ 5	Excellent	Strong link.link (rule of thumb). Consider a lower spreading factor for shorter air time.
0 to 5	Good	Reliable communications. Typical for in-range nodes.
−5 to 0	Marginal	PacketSome packet loss possible.possible Occasionalat retransmitlow expected.SF; still well within the decode floor on long presets.
−10 to −5	Weak (low SF) / usable (long presets)	FrequentOn short presets (low SF) packet loss.loss Borderlinebegins pathhere; -on considerthe adefault relay.LongFast (SF11) preset this range still decodes reliably.
< −10	Very WeakSF-dependent	NearBelow the LoRafloor sensitivityat floor.low MostSF, but on LongFast (SF11/BW250) links down to about −15 dB are still usable and the floor is around −17.5 dB. Only near each preset's own floor will most packets will be lost.

The minimum decodable SNR depends on the spreading factor. At SF7factor: the floor isranges from approximately −7.5 dB;dB at SF7 to about −20 dB at SF12 (LongSlow), itstepping isroughly −202.5 dB.dB per SF (per the SX1276 datasheet / Semtech AN1200.22). The default LongFast preset uses SF11/BW250, giving a floor around −17.5 dB.dB — so a −12 dB link on LongFast is healthy, not weak. Interpret the table above relative to your configured preset.

RSSI - Received Signal Strength Indicator

RSSI measures the absolute power level of the received signal in dBm (decibels relative to 1 milliwatt). A more negative number means a weaker signal. Unlike SNR, RSSI alone does not tell you whether a packet can be decoded - a −120 dBm signal in a quiet environment may decode fine while a −100 dBm signal swamped by noise will not. The bands below are rules of thumb, not published Meshtastic specifications.

RSSI (dBm)	Interpretation
−60 to −80	Very strong.strong (rule of thumb). Nodes are physically close or have excellent antennas.
−80 to −100	Normal operational range for most deployments.
−100 to −115	Weak but decodable at high spreading factors.
< −120	AtConservative orlow-signal threshold. Note the datasheet sensitivity floor is preset-dependent and can reach below sensitivity−140 dBm at high SF/narrow BW, so −120 dBm is a cautious cutoff rather than an absolute floor. Packet loss very likely.

What Healthy Numbers Look Like

A well-configured community mesh with 10 - 30 nodes should exhibit:

• Channel utilization consistently below 15%~25% (the firmware's green/throttle boundary).
• SNR between −5 and +10 dB on all primary relay links.links (and remember the usable floor is lower on long presets).
• RSSI above −115 dBm on relay links.
• Duplicate packet ratio below 10%.
• Zero or near-zero "Rx Bad" packets (CRC failures) unless there is known interference.

Spotting a Congested Network

The most common congestion warning signs:

1. Rising channel utilization: If utilization creeps above 25% during normal operation (not an emergency event), the first remediation step is to increase the position broadcast interval for all nodes. The default 15-minute interval is reasonable for a small network but too aggressive for a mesh with 50+ nodes.
2. High duplicate count: More than 20% duplicates often indicates that too many nodes are configured as ROUTER or that hop limits are set too high, causing the same packet to traverse the network redundantly.
3. Increasing Rx Bad rate: If the ratio of CRC-failed packets is rising, a hidden-node problem or external interference source (other LoRa devices on the same frequency, industrial equipment) is likely the cause.
4. Messages not delivered even to nearby nodes: When a close-range node shows good SNR and RSSI but messages are still failing, the channel is likely saturated and ACKs are being lost.

Node Telemetry Metrics

Each node periodically transmits a DeviceTelemetry packet containing battery voltage, battery level percentage, and (if available) temperature. In the node list you can see these values next to each node. A battery level below 20% combined with low SNR from that node often means the node is running on backup power after a mains failure - an important operational signal in an emergency mesh.