When Should an Inactive Meshtastic Node Be Removed From a Map?

A fair status and retirement policy for public directories that must remain useful without erasing network history.

A map is a claim about current infrastructure

When a public map shows a relay as operational, users and planners may depend on it. Leaving dead sites active creates imaginary coverage and weakens trust. Removing a node too quickly is also misleading because radio observations are intermittent and a healthy device may be unheard by one gateway.

The solution is not one universal timeout. Use different rules for verified infrastructure, community-reported nodes, automatically observed devices and personal mobile nodes.

Classify records before aging them

Record type	Expected behavior	Map treatment
Verified permanent infrastructure	Defined availability and maintainer	Operational status requires continuing evidence
Experimental fixed node	May be intermittent	Show as experimental with expiry or review date
Personal or mobile node	Often switched off or moving	Do not imply permanent coverage
Automatically observed node	Identity and purpose may be unknown	Show last observed, not verified operational
Historical site	No longer active	Separate historical layer or archive

Use status transitions, not sudden deletion

Operational: recent evidence matches the site’s expected reporting and service.
Stale: expected evidence is late, but failure is unconfirmed.
Under review: maintainers or observers are checking conflicting evidence.
Offline: independent evidence supports current unavailability.
Retired: the site has ended, permission has lapsed or no recovery is planned.
Archived: retained for history but excluded from current coverage and routing plans.

A directory may hide offline records from the default operational layer without deleting their history. “Removed from the active map” and “erased from the database” are different actions.

Choose timeouts from expected reporting

A mains-powered gateway expected every hour can be considered stale much sooner than a low-power solar relay deliberately transmitting health data twice per day. Establish the expectation in the site record. A useful policy might mark a node stale after several missed expected periods, begin review after independent observers also fail, and mark it offline after maintainer confirmation or sustained evidence.

Calendar duration alone is not sufficient. Weather, seasonal shutdown, planned work, changed observers and network partitions should influence status. Publish the last verified date and the reason for the classification.

Require more than “last heard”

Last-heard timestamps can come from one observer, MQTT bridge or cached application. Check multiple radio observers where possible, expected telemetry, known links, recent configuration changes and host or maintainer reports. A NodeInfo packet proves that the node transmitted; it does not prove its intended coverage or relay service.

Meshtastic NodeDB capacity is limited on embedded devices, so a node disappearing from one list may reflect local database turnover rather than radio failure. Directory systems should preserve their own provenance: who observed the packet, when and through which path.

Contact the steward

Verified infrastructure should have a maintainer contact. Send a clear status query containing the site identifier, last evidence and proposed map action. Allow a reasonable response period. If the steward confirms planned maintenance or seasonal operation, show that information and a review date.

If no steward remains, reclassify the site as unmaintained even if occasional packets continue. The community may seek a successor, but should not advertise an unmanaged node as dependable backbone infrastructure.

Retire records for clear reasons

The host or owner confirms permanent removal.
Site permission or power has ended.
The equipment was replaced by a new stable site identity.
Repeated checks show long-term absence and no steward responds.
The listing is duplicate, incorrectly located or not public infrastructure.
The node creates harmful interference or unsafe operation and will not return.

Document who made the decision, the evidence and whether equipment still needs retrieval. If a replacement uses the same location but different hardware, link the records rather than rewriting history invisibly.

Coverage polygons must age too

Removing a marker while leaving its coverage shaded as active is misleading. Associate coverage evidence with the site, configuration, antenna, date and test method. When the node becomes offline or materially changes, mark the coverage historical until it is revalidated.

Automatically inferred coverage should be labeled as prediction or observation density, not guaranteed service. Public maps become trustworthy when they communicate uncertainty.

Allow correction and restoration

Provide a route for hosts, maintainers and local users to report wrong status. Preserve enough history to restore a record without inventing a new installation date. Before returning an offline node to operational, require fresh observation or commissioning evidence, especially after antenna, power, firmware or location changes.

A practical MeshAtlas policy

For verified infrastructure, store an expected health interval, last independent observation, last maintainer confirmation and next review date. Show stale and offline states visibly. Exclude them from active coverage calculations. Archive retired sites but keep historical tests available in a separate view. For automatically discovered personal nodes, show observations without converting them into permanent infrastructure claims.