Health Checks Reference
The Health Module continuously runs a set of automated checks and rolls each one up into an overall status. This reference provides the full catalog of checks, grouped by component, along with the condition that triggers each check's Warning and Critical status.
Health Status
|
Status |
Meaning |
|---|---|
|
Healthy |
The check passed. Nothing to do. |
|
Warning |
Attention recommended. |
|
Critical |
Urgent. Action required. |
|
Unknown |
The check couldn't run, or the data was unavailable. This isn't a failure. For example, a feature is disabled, or the search cluster is externally managed. |
Check Behavior and Scope
|
Behavior |
Details |
|---|---|
|
Usage-based checks |
Averaged over a rolling 10-minute window (disk, memory, buffers, CPU), so a brief spike doesn't flip the status. |
|
State-based checks |
Change status only after the condition holds for roughly 30 seconds (connectivity, processing state). |
|
Scope |
Some checks run per Graylog node (a single node can show Warning while others are healthy); others run once for the whole cluster. |
Graylog Server Checks
|
Check |
What It Monitors |
Warns When |
Critical When |
|---|---|---|---|
|
Disk usage (node) |
Free space on the node's data/journal directory |
≥ 85% |
Usage ≥ 95% |
|
JVM heap (node) |
Java Virtual Machine (JVM) heap memory used by the Graylog process |
≥ 80% |
≥ 90% |
|
Message processing state |
Whether the node is processing messages |
Processing paused, or node shutting down |
Processing has failed |
|
Load balancer status |
The node's load balancer health signal |
Status not ALIVE (for example, throttled or manual override) |
Status DEAD |
|
Input buffer |
How full the input buffer is |
≥ 90% |
≥ 95% |
|
Failing inputs |
Inputs that fail to start or run |
One or more inputs failing |
Never Critical |
|
Processing buffer |
How full the processing buffer is |
≥ 90% |
≥ 95% |
|
Disk journal utilization |
How full the on-disk message journal is versus its limit |
≥ 80% |
≥ 95% |
|
Output buffer |
How full the output buffer is |
≥ 90% |
≥ 95% |
|
Report generation |
Scheduled report runs |
One or more reports failed to generate or deliver |
Never Critical |
|
Archiving failures |
Archive jobs with active errors |
Failures reach the configured archive-failure threshold |
Never Critical |
|
Data Lake message drops |
How full the local Data Lake write buffer (journal) is. A full buffer means messages are being dropped |
Usage ≥ configured threshold |
Journal 100% full (messages may be dropping) |
|
Node indexing lag |
How far a node's indexing trails the furthest-ahead node |
Lags peers by more than 2 minutes |
Lags peers by more than 5 minutes |
|
Data Lake connectivity |
Reachability of the active Data Lake backend |
Never warns |
Backend unreachable (after approximately 30 seconds). No backend configured = Healthy |
MongoDB Checks
|
Check |
What It Monitors |
Warns When |
Critical When |
|---|---|---|---|
|
Connectivity |
Whether Graylog can reach MongoDB |
Never warns |
MongoDB unreachable |
|
Replica-set primary |
Whether a primary is elected in the replica set |
Never warns |
No primary elected. Standalone MongoDB = Healthy |
|
Storage |
Database storage used |
≥ 85% |
≥ 95% |
|
Slow queries |
Slow (greater than 100 ms) queries in the recent window |
1 or more slow queries |
10 or more slow queries |
Slow-query monitoring requires MongoDB profiling to be enabled. Otherwise, this check reports Healthy.
Search Cluster Checks
|
Check |
What It Monitors |
Warns When |
Critical When |
|---|---|---|---|
|
Cluster state |
The search cluster's overall status color |
Cluster Yellow |
Cluster Red |
|
Warm-tier move |
Warm-tier snapshot moves per index set |
A warm-tier move failed or was partial |
Never Critical |
|
Node disk usage |
Disk used per search-cluster node |
≥ 85% |
≥ 95% |
|
Node CPU |
CPU used per search-cluster node |
≥ 90% |
≥ 95% |
|
Node heap |
JVM heap used per search-cluster node |
≥ 80% |
≥ 90% |
|
Node certificates |
TLS certificate expiry on data nodes |
Expires in fewer than 30 days |
Expires in fewer than 7 days, or already expired |
|
Shard count per node |
Shards per GB of heap on each hot data node |
More than 20 shards/GB |
More than 25 shards/GB |
Node CPU, heap, certificate, and shard-count checks report Unknown for externally managed OpenSearch, or for Elasticsearch 7, where the required data isn't available.
Thresholds shown above are product defaults. The archiving failure and Data Lake journal thresholds are configurable; the rest are fixed.
Further Reading
Explore the following additional resource and recommended reading to expand your knowledge on related topics:
