Check the result, not just the process
A running service may be reading an old file. A connected feeder may have no accepted positions. A map can retain the last thing it knew. Your health check should follow the chain far enough to establish useful current output.
For your own station, define a normal period and what an unexplained gap means. Account for local traffic. "No aircraft for a minute" is not a universal failure condition. "The snapshot timestamp has not advanced" is a more direct question about the software path.
Graphs1090 can help observe the receiver and host over time. Use the graphs your chosen installation provides, and confirm which are local statistics rather than remote or combined traffic. [1]
A routine you can keep
| When | Suggested check | Evidence to keep |
|---|---|---|
| After a change | Local reception, all intended feeds, restart recovery and private configuration backup. | Version, exact change, result and rollback. |
| Weekly | Fresh snapshots, destination acceptance, unexpected restarts and available storage. | Only anomalies worth investigating. |
| Monthly | Update notices, backup usability and station-account status. | What was updated or deliberately held back. |
| After moving equipment | Safe mounting, connections, antenna location settings and before/after reception. | New position and the comparison period. |
This is a suggested schedule, not a service-level guarantee. Adapt it to the station's importance and how difficult it is to reach.
Update one layer at a time
Record the decoder or image version, read the relevant release notes and check compatibility before updating. Keep a known-good recovery route. Avoid changing the host OS, radio configuration and every feed client together unless the platform explicitly requires a coordinated upgrade.
After an update, check the local map and every intended destination. Verify source labels and timestamps when a format changes. Reboot when appropriate to prove persistence, not merely that a manually started process works.
For container deployments, retain the configuration and image identifiers required by your rollback procedure. For image-based appliances, follow the project's backup and recovery guidance. A backup you cannot restore is an optimistic collection of files. [2] [3]
Keep records small and useful
Do not turn on every history option simply because storage appears cheap. Decide what you need to diagnose or analyse, how long you need it, and how it will be removed. Decoder history, application logs and retained aircraft data have different purposes.
Preserve enough evidence around an incident to understand it. Avoid saving secrets in logs, and check data-use terms before retaining or redistributing third-party feeds. Document the distinction between your own reception and data obtained elsewhere.
When you ask another enthusiast to help, a tidy station notebook is kinder than a screenshot of forty terminal windows. The radio will not appreciate the difference. The enthusiast will.
Sources and review notes
Documentation reviewed on 19 September 2026. Links lead to the source owners. Versions, account benefits and service terms can change. Hardware installation is not independently bench-tested for this edition.
- wiedehopf / graphs1090Maintainer repository. Receiver and system monitoring.
- SDR Enthusiasts: ADS-B reception and sharingProject documentation. Container-oriented setup and operating guidance.
- dirkhh / adsb-feeder-imageMaintainer repository. The project behind ADSB.im.