Dataplicity LensLinux + macOS
GitHub
Suite / lens-health
System checks

Review problems in one place.

Bring process, service, log, storage, network and hardware signals into one ordered list, then open a finding to see the evidence behind it.

Quick start

shell 
lens-health
lens-health --once
lens-health --plain
lens-health --filter disk
lens-health --json

With no flags, lens-health opens the interactive findings list. The first screen shows severity and a concise title. Select a row and press Enter for its summary, evidence, related system entities and suggested checks.

A useful first pass on an unfamiliar device

  1. Start with critical findings. They represent conditions already affecting operation, such as a full filesystem or failed service.
  2. Open the finding and read the evidence value before acting. A title is a prompt to investigate, not a diagnosis of root cause.
  3. Use the named process, service, mount or interface to move into the matching specialist command.
  4. Review attention findings after immediate failures. They often identify pressure or exposure that may become an incident.
  5. Check collection warnings. A short findings list is only meaningful when the required source data was available.
Health is an index, not an automatic repair tool.

It points to the system state that crossed a check and gives a practical next place to look. It does not claim that one observed symptom proves the underlying cause.

Reading a finding

SeverityCritical needs immediate attention; Attention warrants investigation; informational findings provide context.
SummaryA short statement of the condition Lens observed.
EvidenceThe measured state that triggered the check: a percentage, count, state, route or matching message volume.
Related entitiesThe exact process, service, mount, interface or socket involved where Lens can identify it.
What to checkA focused next inspection, not an instruction to make an unreviewed change.

Finding identifiers are stable enough to use in local scripts within the schema-v2 contract. Read the structured severity, evidence and relationship fields rather than parsing the prose title.

Checks included

AreaExamplesContinue with
HostHigh load, swap pressure, sustained CPU use and unusual process countlens-top
ProcessesZombies, high CPU, high memory and growing memory uselens-top
ServicesFailed units and probable restart loopslens-services
StorageFilesystem capacity pressurelens-disk
NetworkNo default route, down physical interfaces and wildcard listenerslens-net
HardwareHigh temperatures, power constraints and thermal throttlinglens-hardware
LogsError volume and messages around crash or failure conditionslens-logs

Checks run when their source data is present. Collection warnings identify sources that need attention before treating an empty finding set as complete.

Interaction

↑ ↓ / j kMove through findings
EnterOpen evidence and suggested checks
EscReturn to the findings list
/Filter the current findings
rCollect a fresh health snapshot
!Open a local diagnostic shell beside the view
qQuit

Collection continues without blocking navigation. The header distinguishes loading from live data, and a refresh preserves the selected finding when it still exists.

Filters and output

shell 
# Only storage-related findings
lens-health --plain --filter disk

# Keep every finding and consume schema-v2 JSON
lens-health --json --limit 0

--filter is a case-insensitive text match across the rendered finding context. The default limit is 1,000 rows; --limit 0 removes it. JSON returns the shared snapshot shape, including findings, related entities and collection_warnings.

Reading a healthy result

A healthy result means the checks with available source data found no matching conditions at collection time. Collection warnings are separate from findings and identify sources that need attention before treating a scheduled result as complete.

For scheduled use, inspect both findings and collection_warnings, then follow the relevant specialist view when a source or finding needs investigation.