View ping statistics for a particular device

That's an interesting idea.

Do you mean a ping success/failure counter across multiple scan rounds, i.e. when background scanning is enabled? For example, if the device responds during a round, we increment the success counter by 1; otherwise, we increment the failure counter by 1.

Or do you mean sending multiple probes within a single scan round and tracking how many succeed or fail?

Thank you, that's very helpful. The approach we are considering is a small built-in history database that records every scan result: timestamp, IP, MAC, success or failure, and response time. From that single stream of data, the following would all become possible:

• Pings sent, succeeded and failed counters per device, as you described.
• Traffic light status on the device row — green above your configured success threshold, yellow in between, red for no response, measured over a rolling window. Both the thresholds and the window length would be user-configurable.
• Per-device history panel (via right-click) showing every IP the device has held, every hostname it has announced, success rate over time, and an RTT graph. This is particularly useful for identifying intermittent issues that manifest as latency spikes rather than outright failures.
• Reverse view by IP address — selecting an address shows every MAC that has ever responded at it. Helpful for static assignments and for diagnosing DHCP collisions.
• Stale candidates report listing devices not seen for a configurable number of days — the original wasted-IP reclamation use case.

We've implemented history recording, in which every scan round records found devices in a compact form.

This easily enables simple first-seen, last-seen, and availability tracking (how many scans the device was online in).

Next, we plan to derive additional reports and insights from the same dataset.

Main grid columns (per-device, one value per row)

These are inexpensive to calculate, as they are derived directly from a single device's history in addition to the existing First Seen, Last Seen and Availability metrics:

• New device — First Seen equals the current session. This can be highlighted or colour-coded as the most security-relevant signal.
• RTT trend — average RTT compared to recent history, helping identify gradually increasing latency.

Separate reports (aggregate and temporal analysis)

Inventory & change tracking

• New devices report — all devices first detected within a selected date range. This becomes the primary security and audit report.
• Disappeared devices — devices not seen for N days, useful for identifying decommissioned, offline or potentially stolen equipment.
• Network growth — device count trends over time, optionally grouped by network.

Reliability analysis

• Availability ranking — percentage uptime per device over a selected period, useful for identifying unstable infrastructure.
• Always-on vs intermittent — distinguishes permanently online devices (servers, infrastructure) from intermittently connected devices (phones, laptops), enabling automatic role classification.

Identity & addressing

• IP history / DHCP churn — MAC-to-IP history over time, highlighting devices that frequently change addresses.
• Hostname history — tracks hostname changes for each device.

If you have any ideas what else could be useful, please let us know. (v)

It's just that an existing column was reused and two new ones added, but due to the architecture the new columns are added at the end.

You can simply drag the Last Seen column to the group where the First Seen column is, or vice versa.

I'll check if we can fix this discrepancy (tu)