Use Lantern with a clear understanding of its results

Installation / first run

Install the service, then open its local interface

1. Run the 64-bit Windows installer as an administrator.
2. The installer creates the machine-wide LanternNetworkMonitor service under the built-in LocalService account and configures automatic startup.
3. The service starts during installation. The tray application is then launched for the current user and is registered to start for that user at sign-in.
4. Open Lantern by double-clicking the tray icon or choosing Open Lantern Network Monitor. The default address is http://127.0.0.1:8080.

The default listener is loopback-only. Other machines cannot use that URL to reach Lantern, and v1.6.7 does not expose a web setting for remote access. Windows Firewall or endpoint protection can still affect ICMP replies.

Dashboard

Read current state together with the selected history window

The Dashboard is grouped by saved dashboard groups, plus Ungrouped when needed. Choose tile or list view. Each host shows its current state and current latency, along with packet loss, availability, and events calculated for the selected timeframe.

• State: Unknown, Online, Degraded, Offline, or Disabled.
• Latency: the latest ICMP round-trip time when the latest probe succeeded; a failed latest probe displays no latency value.
• Packet loss: failed probes divided by probes in the selected retained range.
• Availability: successful probes divided by probes in that range. “No data” is different from zero availability.
• Events: online/offline transitions and degraded start/recovery events that overlap the range.

The Timeframe selector includes recent, calendar, longer, custom, and all-retained choices. Group and host selectors are searchable, accept multiple selections, are saved in the browser, and combine as filters. Tile/list choice is also saved locally. Drag host cards or group headers to save order; ordering is intentionally unavailable while filters are active.

Select a host name to open its detail page. Use the host menu to edit, enable/disable, or delete it. Deleting a host removes that host and its related history; treat it as permanent.

Groups

Organize presentation without changing probe behavior

Choose Add Group, enter a unique non-empty name, and save. A group controls Dashboard organization and filtering; it does not alter monitoring interval, thresholds, or diagnostic logic. Empty groups remain visible and can be reordered.

Use a group’s controls to rename or delete it. Renaming updates the member hosts’ group name. Deleting a group preserves its hosts and their history by moving them to Ungrouped. You can also drag a host between groups.

Adding hosts

Define exactly what Lantern should probe

Choose Add Host and complete the fields:

• Display name: required label shown in the UI.
• Hostname or IP address: required IPv4/IPv6 address or valid DNS name. URL schemes, paths, host-and-port values, whitespace inside the target, and invalid host labels are rejected. Each normalized target must be unique.
• Description: optional context.
• Group: an existing group, or Ungrouped.
• Tags: optional comma-separated text stored for context. Tags do not drive Dashboard filtering in v1.6.7.
• Latency threshold: optional positive value in milliseconds. If omitted, the application default of 100 ms is used for degradation evaluation.
• Enable monitoring: starts probing after the host is saved. A disabled host remains configured but is not probed.
• Gateway / DNS Server roles: optional infrastructure roles used by Advanced Diagnostics. These roles do not enable diagnostics for the host itself.

After creation, an enabled host begins in Unknown until a probe establishes state. v1.6.7 keeps the Add Host dialog open after a successful addition for rapid entry: the name, target, description, and role checks reset, while group, tags, threshold, and enabled choice are retained. Editing an existing host closes the dialog after save.

Host monitoring

Understand state transitions before interpreting an alert

By default, each enabled host is probed with native ICMP every 5 seconds with a 2-second timeout. The defaults are not editable on the Settings page.

• Online: a host with a healthy successful reply. The first success takes an Unknown host Online.
• Offline: three consecutive failures confirm an outage. The outage start is backdated to the first failure in that sequence.
• Recovered: two consecutive successes return an Offline host to Online and close its outage. The recovery timestamp is the second successful probe.
• Degraded — latency: at least three of the latest five successful latency samples are above the host threshold.
• Degraded — packet loss: rolling loss is at or above 20% in the latest 60-second window.
• Degraded recovery: three consecutive successful probes that meet both healthy conditions return the host to Online.

A degraded host has not met the Offline failure threshold, but its recent evidence meets a latency or packet-loss rule. Degradation creates its own event; it does not create an outage. Consecutive failures still take a degraded host Offline, while confirmed outage recovery can return to Degraded if the recovered response remains unhealthy.

ICMP measures reachability from the Lantern machine, not every application protocol. A failed probe can mean the host or path is unavailable, DNS resolution failed, a firewall blocked ICMP, or the timeout was exceeded.

Network Overview

Compare patterns using retained graph data

Overview renders one host panel at a time with latency and packet-loss history. Filter by multiple groups or hosts, search selectors, expand a graph, and drag panels into a saved order when no filters are active.

Timeframes include 1 hour, 6 hours, 24 hours, 2/7/14/30 days, calendar periods, 2/6/12 months, and a custom local date/time range. Overview also supports all retained data. Resolution choices run from raw 5-second data through one-day buckets; Auto chooses a safe resolution and the UI reports the actual resolution used.

Older ranges may have lower resolution because raw samples roll into minute data and minute data into hourly data. If the selected resolution no longer exists for the oldest part of a range, fewer points or a gap can be expected. Packet-loss graphs show failed-probe percentage for each bucket; latency values use successful probes only.

Host detail

Select a host from the Dashboard or Outage History to open its detail view. It shows current state, latest latency, lifetime successful/failed-probe counters, synchronized latency, loss, availability, and outage graphs, plus degraded periods. Pan or zoom the graphs and expand individual panels. Raw retained five-second samples appear newest first in pages of 100 with timestamp, success/failure, latency, and result.

The detail page also links to monitoring-history CSV export. The export API accepts the fixed 1-hour, 6-hour, 24-hour, 7-day, and 30-day ranges; longer, calendar, all-retained, and custom graph selections are not supported by that v1.6.7 CSV endpoint.

Advanced Diagnostics

Correlate a target failure with local infrastructure and route evidence

1. Configure Diagnostic Infrastructure

Edit monitored hosts on the Dashboard and assign Gateway or DNS Server. The infrastructure panel lists these role assignments. Windows route selection determines the target's next-hop gateway; a Gateway role associates that address with a monitored host when it matches, rather than defining a gateway to force into the route. Every DNS-role host is checked for ICMP reachability and, when a DNS test hostname is configured, queried directly for that name. v1.6.7 does not designate primary versus secondary DNS roles—all explicitly assigned DNS servers participate.

v1.6.7 has no Internet role. An Internet reference such as a public IP or hostname is simply a monitored target with Advanced Diagnostics enabled.

2. Configure targets

In Advanced Diagnostic Targets, enable individual hosts or all hosts in a group. This flag controls whether a host can be diagnosed and whether outage/recovery automation is created for it; it does not change normal ICMP monitoring. The UI warns above the recommended maximum of 10 enabled targets, but that recommendation is not a hard target limit.

The optional DNS test hostname must be a hostname or FQDN—not a URL, path, or host-and-port. Leave it blank if only DNS-server reachability should be tested.

3. Run and interpret diagnostics

Run now queues a manual run. A run captures the target and current infrastructure configuration, then collects:

• Target Reachability: three ICMP probes, packet loss, and successful-reply latency statistics.
• Route Context: target resolution and the route/interface information Windows selects.
• Gateway: three ICMP probes to the next-hop gateway selected for that target; a matching Gateway-role host supplies monitored-host context.
• DNS: three ICMP probes for each configured DNS-role host plus a direct query for the configured test hostname, if present.
• Traceroute: up to 30 hops with three probes per hop and a one-second per-probe timeout.

A run is Complete when its applicable components execute without an execution failure, even when reachability evidence reports packet loss. Partial means some component execution failed while useful results remain. Failed means the run could not produce the required execution, and Cancelled means a requested cancellation was observed. “Not applicable” can be normal when no infrastructure role or DNS test hostname is configured.

Automatic diagnostics

For an enabled target, Lantern creates a durable automatic run when a confirmed outage opens and another when that outage recovers. Degraded state alone does not trigger automatic diagnostics. Runs survive queue pressure and are reconciled by the application; disabling the target prevents new automatic runs but does not cancel a run already accepted.

Diagnostic History

Choose 1 hour, 6 hours, 24 hours, 7 days, 30 days, or All, and optionally focus history on one host from its target controls. The table shows time, host, trigger reason, run status, target result, and actions, with Load More for additional records. Open a run to inspect each component, cancel a queued/running run, rerun a finished target manually, or delete a finished record. Active runs cannot be deleted. v1.6.7 has no status, trigger, or free-text history filter. Retention cleanup removes only finished runs old enough for the configured policy.

IP Scanner

Discover responders within a bounded IPv4 range

Enter either an IPv4 CIDR or explicit start and end addresses. The resulting inclusive range must contain no more than 1,024 addresses and must be wholly private, link-local, or loopback; unspecified, multicast, reserved, public, and mixed-category ranges are rejected.

Lantern first uses ARP discovery where the range is on a directly connected local subnet, then performs concurrent ICMP discovery. A result means the address answered at least one supported discovery method. Progress reports scanned addresses, discovered devices, elapsed time, and scan state. You can cancel an active scan; partial results remain visible.

After discovery, Lantern attempts best-effort enrichment. Hostname can come from reverse DNS or local Windows neighbor/name information. MAC address is generally available only from local neighbor data. Manufacturer is looked up from the bundled offline OUI data when a MAC prefix is known. Any of these fields may be blank and none is proof of device identity.

Select one or more results and add them to monitoring. Existing configured targets and duplicate selected addresses are skipped. New entries use the discovered hostname when present, otherwise the IP address; they are enabled, Ungrouped, and tagged scanner. You can edit them afterward on the Dashboard.

Outage History

Review confirmed active and recovered interruptions

An outage record is created only when the host reaches Offline after the configured consecutive-failure threshold. Its start is the first failure in the confirming sequence. While active, the recovery field is empty and duration continues to increase. Recovery closes the record after the configured consecutive-success threshold.

The page follows the saved Dashboard group and host order. Each group summarizes its host count, outage count, and latest incident. Expand a group and host to see Started, Recovery, Duration, and Ongoing/Recovered state. Hosts with no incidents in the chosen period remain visible.

Choose 1 hour, 6 hours, 24 hours, 7 days, 30 days, or All. The browser remembers this range, and the hierarchy refreshes approximately every 10 seconds. v1.6.7 does not provide group, host, or state filters, column sorting, custom dates, or pagination on this page.

Export CSV is independent of the selected on-page range. It exports the newest stored outages, up to 5,000, with database outage/host fields including IDs, host name and target, start, recovery, duration, and open state. It is a direct CSV export, so treat fields as untrusted when opening the file in spreadsheet software.

Latency or packet-loss degradation is not an outage and is recorded separately. Retention selectors do not automatically prune outage records. Clear Monitoring History removes recovered outages but preserves active ones.

Application Health

Check the application and monitoring loop

Application Health refreshes these operational indicators:

• Version: the running package version.
• Application uptime: time since the current application process started.
• Database size: combined main SQLite, WAL, and shared-memory file size.
• Hosts: configured and enabled counts.
• Active monitors: current monitor-task count.
• Latest monitoring cycle: the persisted heartbeat time shown in relative form.
• Recent errors: timestamps and messages for up to the latest 20 monitoring-error records. The database keeps a rolling maximum of 200 such records.

The page refreshes about every 10 seconds. A responding health endpoint reports application status ok; active-task count and latest-cycle recency are evidence users must interpret rather than a separate computed stale-cycle alarm. It does not query or display Windows Service Control Manager state. If the service is fully stopped, the page itself is unavailable.

Settings

Know which controls are actually user-editable

The current Settings page contains four retention selectors, storage statistics, three collected-history actions, database optimization, application paths/version, and service Stop/Restart controls. It does not expose probe interval, timeout, outage thresholds, degraded-loss threshold, listener address, or logging level as browser settings.

Retention changes are validated and saved immediately when a selector changes; no service restart is required. Destructive and service actions require an explicit confirmation dialog. Storage cards refresh after data deletion and database optimization.

Windows service and tray

Separate background monitoring from the user launcher

The Windows service hosts the web interface, scheduler, monitoring engine, diagnostics, scanner service, retention maintenance, and database access. The installer configures it for automatic startup under LocalService. Monitoring continues when the browser is closed or the tray application exits.

The tray application polls the local status endpoint, shows Online/Degraded/Offline counts in its tooltip, and provides Open Lantern Network Monitor and Exit. Exiting removes only the tray process and explicitly leaves monitoring running. Service Stop and Restart are Settings-page controls, not tray-menu items.

The Settings page offers Stop and Restart. Restart temporarily interrupts probes and the web page, then returns when service startup completes. Stop ends monitoring and makes the local UI unavailable; there is intentionally no Start button on a page that cannot run while its own service is stopped. Use Windows Services to start it again.

Data retention

Keep recent precision and older trends separately

The selectors accept only these values:

• Raw samples: 24 hours, 48 hours, 7 days (default), 14 days, or 30 days.
• One-minute history: 30 days, 90 days (default), 180 days, or 1 year.
• One-hour history: 1 year, 2 years (default), 3 years, 5 years, or Forever.
• Diagnostic history: 30 days, 90 days (default), 180 days, 1 year, or Forever.

Maintenance runs during application startup and then approximately hourly. In bounded batches it rolls raw samples older than the raw period into one-minute aggregates before deleting those samples; it rolls old minute records into one-hour aggregates before deleting them; and it deletes hourly or finished diagnostic records beyond their policies unless Forever is selected.

Changing a setting does not immediately launch an on-demand cleanup, but it affects the next maintenance run. Older graph precision will be lost after rollup, and data beyond the final retained tier disappears. Retention does not control outages, degraded events, active diagnostic runs, or monitoring-error records.

Data management

Destructive actions are immediate and not reversible in Lantern

• Clear Monitoring History: deletes every raw sample and minute/hour aggregate, every recovered outage, and every inactive degraded event. Active outages and active degraded events remain. Current host state and lifetime success/failure counters also remain, so those counters do not reset with graph history.
• Clear Diagnostic History: deletes completed, partial, failed, and cancelled runs. Queued and running runs remain and are counted in the result.
• Clear All Data: performs both scopes above. Despite the short label, it does not delete configured hosts, groups, diagnostic roles, retention settings, application metadata, active incidents, active diagnostic runs, or monitoring errors.
• Optimize Database: checkpoints the write-ahead log, runs SQLite compaction, performs a quick integrity check, and checkpoints again. It can reduce physical size when reusable pages exist; it does not promise a reduction and does not delete history or configuration.

All four actions can contend briefly with normal database writes. Only one optimization runs at a time, and shutdown can cancel it safely between/within supported operations. Back up the displayed database file through an appropriate SQLite-aware process before destructive maintenance if the history matters.

Application information / logging

Use the paths reported by the running application

Settings displays the running version, database path, log path, and local web URL. In an installed build, runtime data normally resolves beneath the machine-wide Lantern directory in %ProgramData%; in development or a deliberately configured environment, paths can differ. The displayed values are authoritative for that instance.

The application log uses size-based rotation at 5 MiB, with up to three backup files. Recent monitoring errors also appear in Application Health, but they are not a complete replacement for the log. For support, record the v1.6.7 version, Windows environment, target, time window, visible state, and a sanitized relevant log excerpt. Remove private addresses or names when necessary.

Basic troubleshooting

Start with the observation Lantern actually makes

A host incorrectly appears Offline

1. Confirm the saved hostname/IP and whether the host is enabled.
2. From the Lantern machine, test whether the target answers ICMP. A working web or file service does not prove ICMP is allowed.
3. If a hostname is used, verify it resolves to the intended IPv4 address on that machine.
4. Review the first-failure time and nearby targets. Three consecutive default probes are needed for Offline.
5. Run Advanced Diagnostics if it was enabled; compare target, gateway, and route evidence.

DNS looks broken while IP monitoring works

Assign the actual resolvers as DNS Server role hosts, set a valid DNS test hostname, and run diagnostics. Successful ICMP to a DNS server with a failed direct DNS query can indicate a DNS-service, policy, or query-path problem; ICMP success alone does not test name resolution.

The gateway check fails

Check the route context to confirm the next-hop gateway Windows selected; assign the Gateway role to a monitored host at that address if you want host context attached. Compare ordinary monitoring and diagnostic reachability. Failure can suggest a local adapter, VLAN, Wi-Fi, firewall, gateway, or ICMP-policy issue; route context can help identify which local route Windows selected.

The scanner does not find a device

Verify the inclusive range and 1,024-address limit, and let the scan complete. Scan from the same subnet if ARP/MAC data matters. Devices that ignore ICMP and are absent from the local ARP table will not be discovered. Add a known valid address manually if discovery is not possible.

The service is stopped or the web UI is unavailable

Try http://127.0.0.1:8080 on the Lantern machine. If unavailable, check LanternNetworkMonitor in Windows Services and start it there if appropriate. If it runs but the UI is unavailable, inspect the exact log path under Settings once access returns, or the installed ProgramData log location. Check for another local process using the configured port only if the service log reports a bind failure.

History is missing

Check the Dashboard/Overview timeframe and filters, then review retention. Older samples may have been rolled to minute or hourly resolution, final-tier data may have expired, or a user may have cleared history. “No data” after adding/enabling a host is expected until probes are stored.

Database size or database errors

Use Settings storage statistics to distinguish physical file size from reusable space. Optimize Database can reclaim reusable pages and runs an integrity check, but is not a repair or backup. Preserve the database and logs before further destructive action if integrity or I/O errors recur.