Skip to content
Product

Monitoring modules that stay honest about setup and availability.

PingNodes is a control layer for operational monitoring. This page explains what each public monitoring module checks, what it can detect, and which parts still depend on setup before they become useful.

Current monitoring scope

Each module below uses a textual availability state so PingNodes never relies on color alone or overstates a deferred capability.

n8n execution failures

Available
What PingNodes checks
PingNodes watches n8n workflow execution outcomes for failed runs that need attention.
What problem it detects
Broken or failed workflow executions before a customer reports the problem.
What the customer sees
Operators see the failed workflow context and the related operational event history.
Alert and report behavior
PingNodes can route alert delivery through the configured notification channels.

Silent missed runs

Available
What PingNodes checks
PingNodes watches for scheduled workflows that stop running even when no explicit failure record appears.
What problem it detects
Quiet operational drift where automations stop firing on schedule.
What the customer sees
Operators see that a workflow appears overdue or inactive compared with its expected cadence.
Alert and report behavior
Missed-run findings can enter the same controlled alert and reporting flow as execution failures.

VPS CPU, memory, and disk

Setup required
What PingNodes checks
PingNodes reads host heartbeat and machine-health signals after the VPS connection has been configured.
What problem it detects
Resource pressure, missing heartbeats, and degraded host conditions that affect automation reliability.
What the customer sees
Operators see host-level health states instead of guessing from downstream failures alone.
Alert and report behavior
Host issues can contribute to alerts and reporting once the monitored host is connected.

Docker container health

Setup required
What PingNodes checks
PingNodes uses the VPS-side monitoring path for container-health visibility instead of a completely separate public installer flow.
What problem it detects
Container restarts, unhealthy services, or degraded Docker-backed workloads.
What the customer sees
Operators get a Docker-oriented health view tied to the monitored host context.
Alert and report behavior
Container issues follow the same controlled routing and reporting path once configured.

SSL expiry

Setup required
What PingNodes checks
PingNodes watches registered domains for certificate expiry risk once the SSL targets are configured.
What problem it detects
Certificates approaching expiry before they create service disruption.
What the customer sees
Operators can review which SSL targets still need attention and which ones are healthy.
Alert and report behavior
SSL findings are operational signals, not a promise of automatic certificate renewal.

Backup freshness

Setup required
What PingNodes checks
PingNodes checks whether the expected backup signal or timestamp still looks healthy for the configured source.
What problem it detects
Overdue or stale backups that weaken operational recovery confidence.
What the customer sees
Operators can review backup recency as a monitoring signal rather than a guaranteed restore test.
Alert and report behavior
Backup alerts remain helpful operational signals, and some coverage still depends on configured sources.

What is intentionally outside this page

Website or API uptime is not part of the active public monitoring grid today. Browser Web Push is a notification channel and remains unavailable while its delivery path is under maintenance.

PingNodes should only advertise monitoring modules that have a real or clearly setup-dependent customer path. Hidden, deferred, or unrelated modules should not be presented as active.

Next step

Pair monitoring scope with setup help before you connect anything.

A good monitoring plan starts with the right workspace, the right integrations, and truthful expectations about what PingNodes can observe today.