Healthchecks — how the status dot works

🇩🇪 Deutsch

Mesh has an in-process healthcheck scheduler — no external cron, no additional container.

How it works

• Interval: a full sweep every 10 seconds
• Parallel: p-limit(8) — at most 8 simultaneous pings
• Implementation: apps/web/src/server/healthcheck/scheduler.ts
• Helper: pingTarget(target, fallbackUrl) from pinger.ts

Ping types

http

fetch(url) with AbortController(timeoutMs). Accepted status codes by default: [200, 204, 301, 302, 401].

401 is intentionally included — many services have auth walls but are reachable. If you do not want this, adjust expectStatus in the service editor.

tcp

net.connect({host, port}) with timeout. Successful when the connect succeeds — no response content is checked. Useful for databases, MQTT brokers etc.

none

No ping — status is always "unknown". Useful for cards that are direct-access only without a meaningful healthcheck (e.g. docs page, external cloud service).

Affected fields

Services, network devices and InfraNodes each have a pingTarget field. Widget-specific polls are separate (each widget polls its integration itself, in the React Query layer).

Refresh & UI

• React Query fetches trpc.status.all every 10 s + on refetchOnWindowFocus
• Status dots are green (online), yellow (warning), red (offline), grey (unknown)
• Latency is shown (e.g. "42 ms")

What you can do

• Common issues: see Troubleshooting
• Adjust timeout: in the service editor → pingTimeoutMs (default 3000)
• Extend status code list: in config.json → services[].pingTarget.expectStatus array

Roadmap

• v1.6 — healthcheck interval configurable per service
• v1.6 — optional: SSL certificate expiry warning
• v1.7 — latency history for 24 h (mini sparkline)