Thank you for the detailed report and for the troubleshooting steps you’ve already taken.

We’ve investigated on the Cloud backend side and don’t see a loop from our end (only one context snapshot has been processed for this node, and there are no errors in our logs). This suggests the issue may be on the agent side rather than the backend.

To help us narrow this down, could you run the following command on vps1.alte.pl while the loop is actively occurring:

curl -s 'http://127.0.0.1:19999/api/v1/contexts?options=queue,flags'

This will show us whether any specific contexts are constantly being flagged for update on the agent side, which would explain the version hash mismatch you’re seeing. Please share the full output.

Kind Regards,
Kanela

Thank you for sharing the logs and your claim.conf.

There are two issues at play:

1. SSL certificate verification failure

Your logs show:

SSL: certificate verify error 19: self-signed certificate in certificate chain at depth 2,
subject: DC = INT, DC = BAG, CN = BAG-PKI-CA

Your network has a corporate Certificate Authority (BAG-PKI-CA) performing SSL inspection on outbound connections. The Netdata Agent cannot validate this certificate because it’s not in the standard trusted root store, causing the ACLK connection to fail.

2. Rate limiting (HTTP 429)

The repeated failed connection attempts have triggered a 30-day rate limit backoff on Netdata Cloud. This is why the Next Connection Attempt At is set so far in the future. Restarting the Netdata service after fixing the SSL issue will reset this.

Here are your options, in order of preference:

Option 1: Install the corporate CA certificate (recommended)

Obtain the BAG-PKI-CA certificate from your IT department and import it into the Windows trusted root store:

certutil -addstore "Root" path\to\corporate_ca_cert.cer

Then restart the Netdata service.

Option 2: Configure a corporate proxy

If your organisation routes outbound traffic through a proxy, add it to C:\Program Files\Netdata\etc\netdata\claim.conf:

[global]
    url = https://app.netdata.cloud
    token = YOUR_TOKEN
    rooms = YOUR_ROOM
    proxy = http://proxy.yourcompany.com:8080
    insecure = no

Then restart the Netdata service.

Option 3: Disable SSL verification (last resort only)

If neither option above is possible, you can bypass SSL verification by setting insecure = yes in your claim.conf. This is not recommended as it reduces connection security, but can be used as a temporary measure.

After applying any of the above, restart the Netdata service to clear the rate limit backoff:

net stop Netdata && net start Netdata

Then verify the connection status:

netdatacli aclk-state

Kind Regards,
Kanela

thanks for the quick response!

claim.conf:
[global]
url = https://app.netdata.cloud
token = XX (135 characters)
rooms = XX (36 characters)

#proxy =

insecure = no

Here are the last 100 log-entrys:

daemon:

TimeCreated      : 16.03.2026 13:59:16
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[48]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine/journalfile-1-0000000075.njfv2", file size 1565448 bytes (1.49MiB)

TimeCreated      : 16.03.2026 13:59:16
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[48]): DBENGINE: indexing file "/var/cache/netdata/dbengine/journalfile-1-0000000075.njfv2":
                   extents 247, metrics 4372, pages 26923

TimeCreated      : 16.03.2026 13:59:16
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[48]): DBENGINE: journal file "/var/cache/netdata/dbengine/journalfile-1-0000000075.njf" is ready
                   to be indexed

TimeCreated      : 16.03.2026 13:59:16
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[27]): DBENGINE: created journal file "/var/cache/netdata/dbengine/journalfile-1-0000000076.njf".

TimeCreated      : 16.03.2026 13:59:16
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[27]): DBENGINE: created data file "/var/cache/netdata/dbengine/datafile-1-0000000076.ndf".

TimeCreated      : 16.03.2026 11:11:42
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine/journalfile-1-0000000074.njfv2", file size 1537456 bytes (1.47MiB)

TimeCreated      : 16.03.2026 11:11:42
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: indexing file "/var/cache/netdata/dbengine/journalfile-1-0000000074.njfv2":
                   extents 243, metrics 4226, pages 26487

TimeCreated      : 16.03.2026 11:11:41
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: journal file "/var/cache/netdata/dbengine/journalfile-1-0000000074.njf" is ready
                   to be indexed

TimeCreated      : 16.03.2026 11:11:41
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[33]): DBENGINE: created journal file "/var/cache/netdata/dbengine/journalfile-1-0000000075.njf".

TimeCreated      : 16.03.2026 11:11:41
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[33]): DBENGINE: created data file "/var/cache/netdata/dbengine/datafile-1-0000000075.ndf".

TimeCreated      : 16.03.2026 10:42:14
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine-tier1/journalfile-1-0000000010.njfv2", file size 3064724 bytes (2.92MiB)

TimeCreated      : 16.03.2026 10:42:14
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: indexing file
                   "/var/cache/netdata/dbengine-tier1/journalfile-1-0000000010.njfv2": extents 512, metrics 4178, pages 55808

TimeCreated      : 16.03.2026 10:42:13
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: journal file "/var/cache/netdata/dbengine-tier1/journalfile-1-0000000010.njf" is
                   ready to be indexed

TimeCreated      : 16.03.2026 10:42:13
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[46]): DBENGINE: created journal file
                   "/var/cache/netdata/dbengine-tier1/journalfile-1-0000000011.njf".

TimeCreated      : 16.03.2026 10:42:13
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[46]): DBENGINE: created data file "/var/cache/netdata/dbengine-tier1/datafile-1-0000000011.ndf".

TimeCreated      : 16.03.2026 08:23:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[18]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine/journalfile-1-0000000073.njfv2", file size 1479820 bytes (1.41MiB)

TimeCreated      : 16.03.2026 08:23:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[18]): DBENGINE: indexing file "/var/cache/netdata/dbengine/journalfile-1-0000000073.njfv2":
                   extents 234, metrics 4046, pages 25506

TimeCreated      : 16.03.2026 08:23:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[18]): DBENGINE: journal file "/var/cache/netdata/dbengine/journalfile-1-0000000073.njf" is ready
                   to be indexed

TimeCreated      : 16.03.2026 08:23:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[44]): DBENGINE: created journal file "/var/cache/netdata/dbengine/journalfile-1-0000000074.njf".

TimeCreated      : 16.03.2026 08:23:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[44]): DBENGINE: created data file "/var/cache/netdata/dbengine/datafile-1-0000000074.ndf".

TimeCreated      : 16.03.2026 05:20:08
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[14]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine/journalfile-1-0000000072.njfv2", file size 1548164 bytes (1.48MiB)

TimeCreated      : 16.03.2026 05:20:07
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[14]): DBENGINE: indexing file "/var/cache/netdata/dbengine/journalfile-1-0000000072.njfv2":
                   extents 248, metrics 3734, pages 27032

TimeCreated      : 16.03.2026 05:20:07
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[14]): DBENGINE: journal file "/var/cache/netdata/dbengine/journalfile-1-0000000072.njf" is ready
                   to be indexed

TimeCreated      : 16.03.2026 05:20:07
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[21]): DBENGINE: created journal file "/var/cache/netdata/dbengine/journalfile-1-0000000073.njf".

TimeCreated      : 16.03.2026 05:20:07
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[21]): DBENGINE: created data file "/var/cache/netdata/dbengine/datafile-1-0000000073.ndf".

TimeCreated      : 16.03.2026 02:00:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[33]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine/journalfile-1-0000000071.njfv2", file size 1500964 bytes (1.43MiB)

TimeCreated      : 16.03.2026 02:00:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[33]): DBENGINE: indexing file "/var/cache/netdata/dbengine/journalfile-1-0000000071.njfv2":
                   extents 240, metrics 3686, pages 26160

TimeCreated      : 16.03.2026 02:00:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[33]): DBENGINE: journal file "/var/cache/netdata/dbengine/journalfile-1-0000000071.njf" is ready
                   to be indexed

TimeCreated      : 16.03.2026 02:00:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[15]): DBENGINE: created journal file "/var/cache/netdata/dbengine/journalfile-1-0000000072.njf".

TimeCreated      : 16.03.2026 02:00:02
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[15]): DBENGINE: created data file "/var/cache/netdata/dbengine/datafile-1-0000000072.ndf".

TimeCreated      : 15.03.2026 22:46:12
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine/journalfile-1-0000000070.njfv2", file size 1519308 bytes (1.45MiB)

TimeCreated      : 15.03.2026 22:46:12
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: indexing file "/var/cache/netdata/dbengine/journalfile-1-0000000070.njfv2":
                   extents 244, metrics 3564, pages 26596

TimeCreated      : 15.03.2026 22:46:12
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): DBENGINE: journal file "/var/cache/netdata/dbengine/journalfile-1-0000000070.njf" is ready
                   to be indexed

TimeCreated      : 15.03.2026 22:46:12
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[32]): DBENGINE: created journal file "/var/cache/netdata/dbengine/journalfile-1-0000000071.njf".

TimeCreated      : 15.03.2026 22:46:12
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[32]): DBENGINE: created data file "/var/cache/netdata/dbengine/datafile-1-0000000071.ndf".

TimeCreated      : 15.03.2026 19:27:23
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[40]): DBENGINE: migrated journal file
                   "/var/cache/netdata/dbengine/journalfile-1-0000000069.njfv2", file size 1416948 bytes (1.35MiB)

TimeCreated      : 15.03.2026 19:27:23
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[40]): DBENGINE: indexing file "/var/cache/netdata/dbengine/journalfile-1-0000000069.njfv2":
                   extents 229, metrics 3089, pages 24961

TimeCreated      : 15.03.2026 19:27:23
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[40]): DBENGINE: journal file "/var/cache/netdata/dbengine/journalfile-1-0000000069.njf" is ready
                   to be indexed

TimeCreated      : 15.03.2026 19:27:23
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[28]): DBENGINE: created journal file "/var/cache/netdata/dbengine/journalfile-1-0000000070.njf".

TimeCreated      : 15.03.2026 19:27:23
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[28]): DBENGINE: created data file "/var/cache/netdata/dbengine/datafile-1-0000000070.ndf".

TimeCreated      : 15.03.2026 17:41:56
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[26]): Chart label metadata check completed

TimeCreated      : 15.03.2026 16:43:10
LevelDisplayName : Informationen
Message          : netdata(sensors_upd): heartbeat clock: woke up 77 microseconds earlier than expected (can be due to the
                   CLOCK_REALTIME set to the past).

TimeCreated      : 15.03.2026 16:42:52
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 78 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:42:48
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[3]): Chart metadata check completed

TimeCreated      : 15.03.2026 16:42:42
LevelDisplayName : Informationen
Message          : netdata(UV_WORKER[22]): Dimension metadata check completed

TimeCreated      : 15.03.2026 16:42:38
LevelDisplayName : Informationen
Message          : netdata(WIN_PLUGIN[18): heartbeat clock: woke up 77 microseconds earlier than expected (can be due to the
                   CLOCK_REALTIME set to the past).

TimeCreated      : 15.03.2026 16:42:29
LevelDisplayName : Informationen
Message          : netdata(WIN_PLUGIN[17): heartbeat clock: woke up 206 microseconds earlier than expected (can be due to the
                   CLOCK_REALTIME set to the past).

TimeCreated      : 15.03.2026 16:42:16
LevelDisplayName : Informationen
Message          : netdata(sensors_upd): heartbeat clock: woke up 238 microseconds earlier than expected (can be due to the
                   CLOCK_REALTIME set to the past).

TimeCreated      : 15.03.2026 16:42:05
LevelDisplayName : Informationen
Message          : netdata(PREDICT): heartbeat clock: woke up 384 microseconds earlier than expected (can be due to the
                   CLOCK_REALTIME set to the past).

TimeCreated      : 15.03.2026 16:41:55
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 171 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:41:46
LevelDisplayName : Informationen
Message          : netdata(WIN_PLUGIN[17): heartbeat clock: woke up 677 microseconds earlier than expected (can be due to the
                   CLOCK_REALTIME set to the past).

TimeCreated      : 15.03.2026 16:41:35
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 536 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:41:25
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 439 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:41:15
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 496 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:41:05
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 964 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:40:55
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 1722 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:40:45
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 1696 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:40:35
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 2321 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:40:25
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 2395 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:40:15
LevelDisplayName : Informationen
Message          : netdata(PULSE): heartbeat clock: woke up 272 microseconds earlier than expected (can be due to the CLOCK_REALTIME
                   set to the past).

TimeCreated      : 15.03.2026 16:32:01
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): Netdata Cloud, ACLK connection status: /env response code is not 200

TimeCreated      : 15.03.2026 16:32:01
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: Cloud returned EC="zkxmdeEYsK-5542734", Msg-Key:"ErrTooManyRequests",
                   Msg:"ErrTooManyRequests", BlockRetry:false, Backoff:2592000s (-1 unset by cloud)

                      Unix Errno   : 2, No such file or directory
                      Windows Error:


TimeCreated      : 15.03.2026 16:32:01
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: failed to get ACLK environment (ENV response code is not 200) (got 429)

TimeCreated      : 15.03.2026 16:32:01
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: HTTPS "GET" request to "app.netdata.cloud" finished with HTTP code: 429

TimeCreated      : 15.03.2026 16:32:01
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: Connecting to app.netdata.cloud:443 (no proxy)

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: error passing Challenge/Response to get OTP

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): Netdata Cloud, ACLK connection status: https client failed to write http header

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: error getting challenge

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: OTP Challenge failed

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: couldn't process request

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: couldn't write HTTP request header into SSL connection

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: SSL_write Err: SSL_ERROR_SSL

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): SSL: certificate verify error 19:self-signed certificate in certificate chain at depth 2,
                   subject: DC = INT, DC = BAG, CN = BAG-PKI-CA

                      Unix Errno   : 2, No such file or directory
                      Windows Error:


TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: Connecting to api.netdata.cloud:443 (no proxy)

TimeCreated      : 15.03.2026 16:32:00
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: HTTPS "GET" request to "app.netdata.cloud" finished with HTTP code: 200

TimeCreated      : 15.03.2026 16:31:59
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: Connecting to app.netdata.cloud:443 (no proxy)

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: error passing Challenge/Response to get OTP

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): Netdata Cloud, ACLK connection status: https client failed to write http header

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: error getting challenge

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: OTP Challenge failed

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: couldn't process request

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: couldn't write HTTP request header into SSL connection

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: SSL_write Err: SSL_ERROR_SSL

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): SSL: certificate verify error 19:self-signed certificate in certificate chain at depth 2,
                   subject: DC = INT, DC = BAG, CN = BAG-PKI-CA

                      Unix Errno   : 2, No such file or directory
                      Windows Error:


TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: Connecting to api.netdata.cloud:443 (no proxy)

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: HTTPS "GET" request to "app.netdata.cloud" finished with HTTP code: 200

TimeCreated      : 15.03.2026 16:31:58
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: Connecting to app.netdata.cloud:443 (no proxy)

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: error passing Challenge/Response to get OTP

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): Netdata Cloud, ACLK connection status: https client failed to write http header

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: error getting challenge

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: OTP Challenge failed

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: couldn't process request

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: couldn't write HTTP request header into SSL connection

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: SSL_write Err: SSL_ERROR_SSL

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): SSL: certificate verify error 19:self-signed certificate in certificate chain at depth 2,
                   subject: DC = INT, DC = BAG, CN = BAG-PKI-CA

                      Unix Errno   : 2, No such file or directory
                      Windows Error:


TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: Connecting to api.netdata.cloud:443 (no proxy)

TimeCreated      : 15.03.2026 16:31:57
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: HTTPS "GET" request to "app.netdata.cloud" finished with HTTP code: 200

TimeCreated      : 15.03.2026 16:31:56
LevelDisplayName : Informationen
Message          : netdata(ACLK_MAIN): ACLK: Connecting to app.netdata.cloud:443 (no proxy)

TimeCreated      : 15.03.2026 16:31:55
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): ACLK: error passing Challenge/Response to get OTP

TimeCreated      : 15.03.2026 16:31:55
LevelDisplayName : Fehler
Message          : netdata(ACLK_MAIN): Netdata Cloud, ACLK connection status: https client failed to write http header

The aclk-log seems to be empty.

Kinde Regards,

Joshua

Thank you for running those tests and for providing the output.

The ErrInvalidClaimID error suggests there may be an issue with the claim_id in your configuration file. Could you please share the contents of your claim.conf file? You can find it at:

C:\Program Files\Netdata\etc\netdata\claim.conf

Additionally, could you share the logs from Windows Event Viewer? First, list the available Netdata log channels:

wevtutil el | Select-String "Netdata"

Then retrieve the logs from the most relevant channels for this issue:

Get-WinEvent -LogName "Netdata/Daemon" -MaxEvents 100
Get-WinEvent -LogName "Netdata/Aclk" -MaxEvents 100

This should help us understand what’s happening on your system.

Kind Regards,
Kanela

i tryed your steps:

Step 1:

DNS:

Name                                           Type   TTL   Section    IPAddress

app.netdata.cloud                              AAAA   300   Answer     2606:4700:10::ac42:aad8
app.netdata.cloud                              AAAA   300   Answer     2606:4700:10::6814:1602
app.netdata.cloud                              A      300   Answer     104.20.22.2
app.netdata.cloud                              A      300   Answer     172.66.170.216

HTTPS:

StatusCode : 200
StatusDescription : OK
Content :
RawContent : HTTP/1.1 200 OK
Connection: keep-alive
access-control-allow-credentials: true
Server-Timing: cfCacheStatus;desc=“DYNAMIC”,cfEdge;dur=5,cfOrigin;dur=82
x-content-type-options: nosniff
x-frame-opti…
Forms :
Headers : {[Connection, keep-alive], [access-control-allow-credentials, true], [Server-Timing,
cfCacheStatus;desc=“DYNAMIC”,cfEdge;dur=5,cfOrigin;dur=82], [x-content-type-options, nosniff]…}
Images : {}
InputFields : {}
Links : {}
ParsedHtml :
RawContentLength : 0

Endpoint Test:

I receive an error: {“errorCode”:“dFLf2q4g4x-6441850”,“errorMsgKey”:“ErrInvalidClaimID”,“errorMessage”:“claim_id not a
valid UUID”,“errorRetryDelaySeconds”:2592000}

If i try it with the claimed_id from the cloud.d folder (https://app.netdata.cloud/api/v1/env?claim_id=XX) i get another error: {“errorCode”:“zkxmdeEYsK-6450361”,“errorMsgKey”:“ErrUnsupportedAgent”,“errorMessage”:“do not
retry: unsupported agent”,“errorRetryDelaySeconds”:2592000}

I couldnt find any proxy or TLS configuration problems.

Netdata Logs:

LogMode   MaximumSizeInBytes RecordCount LogName
-------   ------------------ ----------- -------
Circular             1052672         116 Netdata/Access
Circular             1052672           0 Netdata/Aclk
Circular             1052672         615 Netdata/Collectors
Circular             1052672         821 Netdata/Daemon
Circular             1052672          64 Netdata/Health

I still cant find any usefull log files. Is this normal?

Verzeichnis: C:\Program Files\Netdata\var\log\netdata

Mode                LastWriteTime         Length Name




-a----       15.03.2026     16:11              0 aclk.log
-a----       15.03.2026     16:11            302 service.log

Do the errors tell you whats wrong here?

Thanks and Kind Regards,

Joshua

Hello,

I have two identical VPS servers (OVH, Debian 12, HestiaCP 1.9, Netdata v2.9.0) in the same Space. The second node (vps2.alte.pl) works perfectly and shows all metrics in Netdata Cloud. The first node (vps1.alte.pl) connects successfully but never shows any metrics — only dashes.

Node details:

• Hostname: vps1.alte.pl
• node_id: 85b3879e-ee03-402c-a844-79024a79ba4b
• claim_id: 844e427a-a3dd-4c2c-aaff-689067be12bc
• uid: 9ca2c3d3-fdf9-4c5b-bf2b-5e2d6abd9d7f

What works:

• ACLK connection is established successfully (ACLK: connection successfully established)
• Agent is claimed (agent-claimed: true, aclk-available: true)
• Local data collection works perfectly — system.cpu, system.ram, system.net, disk.* and 1800+ charts are all available via the local API at http://127.0.0.1:19999
• Example: curl http://127.0.0.1:19999/api/v1/data?chart=system.cpu returns real values

What does NOT work:

• Netdata Cloud shows dashes for all metrics (CPU, Memory, Load, Disk Read)
• The node is stuck in an infinite loop visible in the logs

Error from journalctl:

RRDCONTEXT: received checkpoint command for claim id '844e427a-a3dd-4c2c-aaff-689067be12bc', node id '85b3879e-ee03-402c-a844-79024a79ba4b', while node 'vps1.alte.pl' has an active context streaming.
RRDCONTEXT: received version hash 1710 for host 'vps1.alte.pl', does not match our version hash 1830. Sending snapshot of all contexts.
NODES INFO: 0 nodes loading contexts, 0 receiving replication, 0 sending replication, 1 pending context post processing (host 'vps1.alte.pl')

This loop repeats continuously — Cloud sends a checkpoint command while the agent is already streaming contexts, causing a version hash mismatch, which triggers a new snapshot, which causes another checkpoint, and so on.

What I have already tried:

• Multiple reinstalls (full purge including /var/lib/netdata, /var/cache/netdata, /etc/netdata)
• Clearing all cache: rm -rf /var/cache/netdata/* /var/lib/netdata/context* /var/lib/netdata/db
• Removing cloud identity: rm -rf /var/lib/netdata/cloud.d/ /var/lib/netdata/registry/
• Generating a new UUID manually via uuidgen
• Re-claiming multiple times with netdata-claim.sh
• Each time a new node_id and claim_id are generated, the same loop immediately starts again

My conclusion:
This appears to be a state issue on the Netdata Cloud backend side. The Cloud keeps sending checkpoint commands that conflict with the agent’s active context streaming, and this cannot be resolved from the agent side alone.

Could you please manually clear/reset the state for this node on the backend? I would really appreciate your help.

Thank you!

Thank you for the detailed output.

The error /env response code is not 200 means your agent is reaching Netdata Cloud but the connection is being rejected during the initial handshake. This is almost always a network-level issue specific to this server — firewall rules, a proxy, or TLS configuration that differs from your other two servers.

One important thing to note first: your agent’s next connection attempt is scheduled far in the future due to a backoff from repeated failures. Once you’ve resolved the underlying issue, please restart the Netdata service to force an immediate reconnect:

Restart-Service Netdata

Please work through the following steps:

Step 1: Test connectivity to Netdata Cloud

Run these in PowerShell to confirm the server can reach our infrastructure:

# Test DNS resolution
Resolve-DnsName "app.netdata.cloud"

# Test HTTPS connectivity
Invoke-WebRequest -Uri "https://app.netdata.cloud" -Method HEAD -UseBasicParsing

# Test the specific endpoint the agent uses
Invoke-WebRequest -Uri "https://app.netdata.cloud/api/v1/env" -Method GET -UseBasicParsing

If any of these fail, the issue is network or firewall related.

Step 2: Check firewall rules

Ensure outbound traffic is allowed to app.netdata.cloud on port 443. Check whether this server has any firewall rules or security policies that differ from your other two servers.

Step 3: Check for a proxy

If this server sits behind a corporate proxy, Netdata needs to be configured to use it. Add the following to C:\Program Files\Netdata\etc\netdata\claim.conf:

[global]
    proxy = http://your-proxy-address:port

Step 4: Verify TLS configuration

Older Windows configurations may have TLS 1.2 disabled. Check your current TLS settings:

[System.Net.ServicePointManager]::SecurityProtocol

If TLS 1.2 is not listed, it will need to be enabled at the OS level.

Step 5: Check Netdata logs

To see what Netdata log channels are available on your system and check for relevant errors:

Get-WinEvent -ListLog "*Netdata*" -ErrorAction SilentlyContinue

Please start with Step 1 and share the output. It will tell us immediately whether this is a connectivity or configuration issue.

Kind Regards,
Kanela

thanks for your answer.

ACLK-STATE:

ACLK Available: Yes
ACLK Version: 2
Protocols Supported: Protobuf
Protocol Used: Protobuf
MQTT Version: 5
Claimed: Yes
Claimed Id: XXX (seems correct)
Cloud URL: https://app.netdata.cloud
ACLK Proxy: none
Publish Latency: off
Online: No
Reconnect count: 0
Banned By Cloud: No
Next Connection Attempt At: 2026-04-05 14:11:49

Agent Info API:

                   "cloud":  {
                                 "id":  0,
                                 "status":  "offline",
                                 "since":  1772797723,
                                 "age":  11075,
                                 "claim_id":  XXX (same ID as above),
                                 "url":  "https://app.netdata.cloud",
                                 "reason":  "/env response code is not 200",
                                 "next_check":  1775391109,
                                 "next_in":  2582311

Netdata Logs:

I can’t find any logs under /var/log/netdata/

I can just see a service.log which shows the windows Service getting started.

I tried several reinstallations to reestablish the connection, but it didn’t work.

Thanks and Best Regards

Joshua

The aclk_online() function returns the current state of the WebSocket connection to Netdata Cloud. When it’s false, it means the Agent cannot establish a connection to Netdata Cloud, even though the claiming process may have succeeded.

This could be caused by a multitude of reasons. To help us correctly diagnose the issue, please run these commands on the problematic server:

1. Check Detailed ACLK State

sudo netdatacli aclk-state

This will show us the exact connection status and any error messages.

2. Check Agent Info API

Visit http://YOUR_SERVER_IP:19999/api/v3/info and look at the cloud section for diagnostic information.

3. Check Netdata Logs

# Linux with systemd
sudo journalctl -u netdata --namespace netdata -xe | grep -i aclk

# Linux without systemd
sudo cat /var/log/netdata/daemon.log | grep -i aclk

Look for “CLAIM” related messages to see why the connection failed.

I´m a Netdata cloud business customer. Currently I am trying to install the netdata-agend on mutliple Servers.

This worked well on two servers. On the third, I ran the netdata installer as on the others and linked it using token and roomid. The service is running, but I don’t see it in my active nodes, neither online nor offline. So far, I’ve only noticed one difference in the server configuration: `aclk-available` is set to false. What could be the cause of this, and how do I fix it? I performed the installation process identically on all servers.

Thanks and best regards

Joshua

Since you also reached us through the support portal, let’s transfer this there, as there could be a multitude of reasons as to why you are not seeing data and we will need more info to proceed investigating this.

Rest assured we will resolve this.

Thanks for your feedback! We have an open PR that completely refactors eBPF.plugin (https://github.com/netdata/netdata/pull/21676), and we’re expecting it to be reviewed and to fix this issue soon.

To be sure we haven’t missed anything, would you mind sharing your distribution? That way we can test on a setup just like yours.

In the meantime, you can disable the plugin in netdata.conf or disable specific threads in ebpf.d.conf.

For context, the environment I’m monitoring uses a delta mod as the primary execution layer for our mobile scripts. It seems that when the mod starts injecting logic into the mobile simulator, Netdata’s apps.plugin starts reporting massive amounts of “interrupt” and “softirq” activity on the host machine. I can’t tell if Netdata is struggling to keep up with the rapid-fire process creation or if the mod itself is causing a bottleneck that Netdata is just reporting.

Has anyone here successfully tuned their netdata.conf for high-velocity script environments like this? I’m considering disabling the cgroups collector for these specific containers to see if it lowers the overhead, but I don’t want to lose visibility into the memory usage. Should I be looking into the per_core settings for the eBPF plugin, or is there a way to exclude the executor’s specific child processes from the real-time tracking? I’d love to hear how you guys handle monitoring volatile automation tools without the monitoring agent itself becoming the biggest resource consumer on the box!

Here’s what it looks like when systemctl stop netdata

Problem/Question

Netdata consuming high CPU after OS upgrade (>90%)

• clearing /var/cache/netdata/* did not help.
• systemctl stop netdata, and running the docker instance of netdata had the same performance hit.

I can’t use netdata in my production at this time as it is causing performance issues.

#uname -a

Linux qupapi1 6.12.69+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.69-1 (2026-02-08) x86_64 GNU/Linux

The 5-node limit on local dashboards can’t be manually configured. Node selection only happens through Netdata Cloud’s Space settings.

Your options: connect to Netdata Cloud to manage which nodes appear, access individual nodes directly at their IP:19999 addresses, or upgrade to a paid plan to remove the limit entirely.

Your systemd dropin approach is correct:

# /etc/systemd/system/netdata.service.d/docker-socket.conf
[Service]
Environment="DOCKER_HOST=unix:///run/user/1001/docker.sock"

This is the proper way to configure environment variables for Netdata services. The errors you saw were because the cgroup-name.sh script couldn’t access the Docker socket at the default path /var/run/docker.sock.

For persistent permissions on /run/user/1001/docker.sock, use systemd-tmpfiles:

# Create /etc/tmpfiles.d/docker-netdata.conf
cat > /etc/tmpfiles.d/docker-netdata.conf << 'EOF'
d /run/user/1001 0750 root docker -
EOF

# Apply immediately
sudo systemd-tmpfiles --create

This ensures proper ownership and permissions persist across reboots.

After applying the tmpfiles configuration and rebooting, your containers should appear with their proper names instead of just cgroup IDs.

Let me know if you need any further assistance.

thank’s for the quick response!

I’ve tested your solution but couldn’t get it to work just yet. I’ve seen a lot of errors in `systemctl status netdata.service` like this:

Jan 20 13:10:01 host spawn-plugins[2083975]: SPAWN SERVER: child with pid 2085643 (request 34) exited with exit code 2: /usr/libexec/netdata/plugins.d/cgroup-name.sh /user.slice/user-1001.slice/[email protected]/user.slice/docker-6fd9ff6ae26c3513af664ae40624a260e0ee11758c0c0fcac6c103beaf116806.scope user.slice/user-1001.slice/user_1001.service/user.slice/docker-6fd9ff6ae26c3513af664ae40624a260e0ee11758c0c0fcac6c103beaf116806.scope

It looks like the environment variable in the `netdata.conf` is not properly configured.

To get it working, I needed to:

1. fix the permissions on `/run/user/` and `/run/user//docker.sock`

   root@host:~# chmod 750 /run/user/1001
   root@host:~# chgrp docker /run/user/1001/docker.sock
   root@host:~# ls -la /run/user/
   total 0
   drwxr-xr-x  4 root   root     80 Jan 20 14:53 .
   drwxr-xr-x 32 root   root   1000 Jan 20 14:55 ..
   drwxr-x---  8 docker docker  260 Jan 20 14:55 1001
   root@host:~# ls -la /run/user/1001/docker.sock
   srw-rw---T 1 docker docker 0 Jan 20 14:53 /run/user/1001/docker.sock
   
   
   

2. setting `DOCKER_HOST` using a systemd-dropin:

   root@host:~# cat /etc/systemd/system/netdata.service.d/docker-socket.conf
   [Service]
   Environment="DOCKER_HOST=unix:///run/user/1001/docker.sock"
   

The last challange now is, to get the permissions fixed permanently…. Do you have any idea on that?

Please follow the documentation steps in order to:

1. Install the freeipmi plugin

2. Configure IPMI credentials in netdata.conf

Then, restart Netdata.

(The default ipmi_sensor_state alert will automatically trigger when power supply sensors enter warning or critical states)

I’ll verify the documentation and code to provide the most accurate solution for the rootless Docker cgroup naming issue.

The Easiest Fix:

Configure the DOCKER_HOST environment variable for Netdata to point to the rootless Docker socket.

Edit /etc/netdata/netdata.conf:

[environment variables]
    DOCKER_HOST = unix:///run/user/1001/docker.sock

Then restart Netdata:

sudo systemctl restart netdata

The cgroup-name.sh script (CODE public cgroup-name.sh.in) queries Docker to get container names. By default, it looks for the standard Docker socket at /var/run/docker.sock, which doesn’t exist for rootless Docker. Setting DOCKER_HOST tells the script where to find the rootless socket.

After restarting Netdata, your containers should appear with their proper names instead of just cgroup IDs in the dashboard.

Problem/Question

I’m running netdata as a native service on a Ubuntu system. Netdata itself is running fine and is showing all the relevant metrics.

On the same host, I’m running multiple containers in docker-rootless. Netdata does see the cgroups created, but is not able to retrieve the name of the given cgroup. As a result, the cgroups are shown with their ID only.

The output below shows the structure:

root@host:~# id docker
uid=1001(docker) gid=988(docker) groups=988(docker)

root@host:~# id netdata
uid=105(netdata) gid=107(netdata) groups=107(netdata),4(adm),13(proxy),988(docker)

root@host:~# tree -d /sys/fs/cgroup
/sys/fs/cgroup
├── dev-hugepages.mount
├── dev-mqueue.mount
├── init.scope
├── proc-sys-fs-binfmt_misc.mount
├── sys-fs-fuse-connections.mount
├── sys-kernel-config.mount
├── sys-kernel-debug.mount
├── sys-kernel-tracing.mount
├── system.slice
│   ├── boot.mount
│   ├── containerd.service
│   ├── cron.service
│   ├── dbus.service
│   ├── docker.service
│   ├── docker.socket
│   ├── fail2ban.service
│   ├── haproxy.service
│   ├── lxd-installer.socket
│   ├── ModemManager.service
│   ├── multipathd.service
│   ├── netdata.service
│   ├── networkd-dispatcher.service
│   ├── polkit.service
│   ├── prometheus-node-exporter.service
│   ├── qemu-guest-agent.service
│   ├── rsyslog.service
│   ├── snapd.socket
│   ├── ssh.service
│   ├── ssh.socket
│   ├── systemd-journald.service
│   ├── systemd-logind.service
│   ├── systemd-networkd.service
│   ├── systemd-resolved.service
│   ├── systemd-timesyncd.service
│   ├── systemd-udevd.service
│   │   └── udev
│   ├── system-getty.slice
│   │   └── [email protected]
│   ├── system-modprobe.slice
│   ├── system-systemd\x2dfsck.slice
│   ├── system-systemd\x2djournald.slice
│   │   └── [email protected]
│   ├── system-systemd\x2djournald\x2dvarlink.slice
│   ├── tailscaled.service
│   ├── udisks2.service
│   ├── unattended-upgrades.service
│   └── upower.service
└── user.slice
    ├── user-1000.slice
    │   ├── session-93.scope
    │   └── [email protected]
    │       ├── app.slice
    │       │   ├── dbus.socket
    │       │   └── gpg-agent-ssh.socket
    │       └── init.scope
    └── user-1001.slice
        └── [email protected]
            ├── app.slice
            │   ├── dbus.socket
            │   ├── docker.service
            │   └── gpg-agent-ssh.socket
            ├── init.scope
            ├── session.slice
            │   └── dbus.service
            └── user.slice
                ├── docker-4a7929960ce5ea9edb19ddffa785242cc0f7c9ad5c681976b7e4e8edf12de71c.scope
                ├── docker-5d0c1b3942801899b30b4f697575e47cc998c4571782e2199fa2a9f7201048da.scope
                ├── docker-65d80aed510bae2e4bcfcac8c46e74a067b380caa593328e13421a19bbdf119b.scope
                ├── docker-6fd9ff6ae26c3513af664ae40624a260e0ee11758c0c0fcac6c103beaf116806.scope
                ├── docker-c78b493bf038d30ee6affb56452d19e67411e9d846a24d933028726773510d7c.scope
                ├── docker-d6e0b302d71be92435a21d5a8f829a7c13a2060be248e04c99f8b159bf30c13c.scope
                └── docker-f3cb9da0ce37a41cb813031ed42cd509f0b1f1b0cf1e8dfc63b5160d02c41d3b.scope

Relevant docs you followed/actions you took to solve the issue

Environment/Browser/Agent’s version etc

• Ubuntu 24.04.3 LTS
• netdata v2.8.0-243-nightly

What I expected to happen

resolved cgroup names

We are beginning to test and explore the solution, and we have the following question:

We have a server where one of the power supplies has failed, and we haven’t received any alerts/notifications.

What is the best procedure or the correct configuration to ensure we receive these types of alerts/notifications?

Many thanks for your support.

Problem/Question

Hi, I have an issue where the kickstart will not install when being pushed out by Kandji, I get a failure each time either because of CMake or because the script the fails.

I am unable to resolve this issue and was wondering if there was any assistance.

Relevant docs you followed/actions you took to solve the issue

#!/bin/zsh

set -euo pipefail

LOG_TAG=“Netdata Kickstart”

log(){ echo “$(date ‘+%Y-%m-%d %H:%M:%S %Z’) [$LOG_TAG] $*”; }

export HOME=“/var/root”

export TMPDIR=“/tmp”

CLAIM_TOKEN=“”

CLAIM_ROOMS=“”

CLAIM_URL=“https://app.netdata.cloud”

# Skip if already installed and claimed

if command -v netdata >/dev/null 2>&1 && [[ -d “/usr/local/netdata/cloud.d” ]]; then

log “Netdata already installed and claimed — nothing to do.”

exit 0

fi

log “Downloading Netdata kickstart…”

curl -fsSL https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh

log “Running Netdata kickstart with nightly channel and claim…”

sh /tmp/netdata-kickstart.sh \

–nightly-channel \

–claim-token “$CLAIM_TOKEN” \

–claim-rooms “$CLAIM_ROOMS” \

–claim-url “$CLAIM_URL”

log “ Netdata kickstart completed.”

exit 0

We advise you to install using the stable release channel instead of nightly:

wget -O /tmp/netdata-kickstart.sh ``https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel

Command used: wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

Error details: The system reports a version mismatch between netdata and its plugins:

• netdata-plugin-chartsd depends on netdata (= 2.8.0-172-nightly) but 2.8.0-167-nightly is to be installed.

• netdata-plugin-pythond depends on netdata (= 2.8.0-172-nightly) but 2.8.0-167-nightly is to be installed.

Suggested template:

Problem/Question

Relevant docs you followed/actions you took to solve the issue

Environment/Browser/Agent’s version etc

What I expected to happen

I’m new to Netdata, so sorry in advance if this is not the right place to ask. I have a Proxmox setup and I noticed the following behavior:

If I install Netdata on the Proxmox host using

curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh && sh /tmp/netdata-kickstart.sh

I can see all network-related metrics (traffic, interfaces, etc.) without any issues. However, if I run the exact same command inside an Ubuntu VM running on that Proxmox host, Netdata does not show any network traffic data at all. Everything else seems to work fine, just not the network traffic inside the VM.

Is this expected behavior in virtualized environments like Proxmox, or am I missing some configuration on the VM side?

Thanks a lot for any guidance, and please let me know if I should ask this somewhere else

Thank You!

Is there a way to export Top dashboard–like CPU usage broken down by PID

No, there is no way to do that. Netdata doesn’t store this info.

Using netdata_app_* metrics I can chart process CPU/memory over time, but they are grouped by app_group. In my setup, many processes fall under generic groups like bash, which isn’t very useful.

Is there a way to export Top dashboard–like CPU usage broken down by PID, command/cmdline, or a more granular selector similar to the Top dashboard checkboxes?

For example, currently I see metrics like:

netdata_app_mem_usage_MiB_average{app_group="ModemManager", ...}

but I’m looking to track specific processes over time, not just grouped apps.

Thanks a lot.

template: gpu_usage 
      on: nvidia_smi.gpu_utilization 
  lookup: average -1m 
   units: % 
   every: 1m 
    warn: $this > 80 
    crit: $this > 90 
    info: High GPU usage ${label:product_name}

I’ve been wrestling with this for about 6 hours now and still can’t get this GPU alert to work. I’m starting to think it might actually be impossible! ^^

• Using netdata v2.8.4, agent only, Ubuntu

• Having Nvidia GPU and using nvidia_smi collector. All charts are working correctly under Metrics

• Created gpu.conf under /etc/netdata/health.d with nvidia_smi.gpu_utilization as this was on the usage chart:

  alarm: gpu_usage
     on: nvidia_smi.gpu_utilization
  lookup: average -1m
  units: %
  every: 1m
   warn: $this > 80
   crit: $this > 90
   info: GPU usage monitoring
  

• Above and dozens of configurations did not work. Alert is not showing in web and /api/v1/alarms?all

• No relevant info in Journal and error.log

• To narrow the problem, in above conf I only changed *on: system.ram*and alert appeared successfully. So I guess that must be a bigger problem with nvidia_smi?

Please help, I’m sooo stuck with this

I’m trying to understand whether the data shown in the Top dashboard (especially per-process CPU usage) is exportable, and if so, whether it can be exported via Prometheus.

Additionally, the main purpose I’m looking for is to visualize process-level CPU usage over time (not just a point-in-time snapshot). I’d like to confirm whether this capability already exists in Netdata (either via built-in dashboards or exported metrics), or if the Top dashboard is primarily meant for real-time inspection only.

Specifically:

• Is the data backing the Top dashboard exposed as time-series metrics?

• Can this data be exported via the Prometheus exporter?

• If process CPU usage over time is already supported, which dashboard(s) or metrics should be used?

Relevant docs followed / actions taken

• Looked through Netdata dashboards and explored the Top / Processes views

• Reviewed exporter-related documentation to understand Prometheus support

What I expected to happen

I expected that the data powering the Top dashboard (process CPU usage) would either:

• Be available as historical time-series metrics, and

• Be exportable via Prometheus so it can be visualized externally (e.g., Grafana) over longer time windows.

If the Top dashboard is intentionally real-time only, I’d like to understand what the recommended way is to track process CPU usage trends over time in Netdata.

To clarify how notifications are structured:

• User Settings → Notifications
  This area is intended for personal notification preferences, meaning notifications that only affect you as an individual user. This is why certain notification types, such as Unreachable, are configured there rather than at the space level.

• Space Settings → Alerts & Notifications → Notification Methods
  This section is specifically for space-wide notification delivery methods. These settings determine how notifications are sent to a broader audience, typically through integrations like Slack, PagerDuty, or Email.
  For email in particular, this section only allows enabling or disabling the email integration for the entire space; it does not control individual notification types.

So while the two pages may look visually similar, they serve different purposes: one controls what you personally receive, and the other controls how notifications are delivered at the space level.

Regarding the invisible section you mentioned, you’re absolutely right. That is a UI bug, and I’ve already forwarded it to the frontend team to be fixed.

Let me know if I can assit further.

Does this setting work?

Edit: Sigh. I figured that out as well. You have to separately configure notifications for “Reachable” and “Unreachable”. And look at the user interface:

There’s an invisible section you have to scroll down to, in order to find out that “Unreachable” is a separate notification type.

Naturally.

This is extremely counterintuitive, because the settings page displayed in that pane is very similar to the one displayed under the “Alerts & Notifications > Notification Methods” tab in the space settings, giving the impression that space settings is the right place to look.

Your Netdata Agent update is failing due to an unmet dependency for the optional netdata-plugin-ibm package. This plugin requires libodbc2 (version ≥ 2.3.1) which is not installed or cannot be satisfied on your system.

Most users do not need this plugin.

If that’s the case for you too, you can simply remove it. To do so,

sudo apt remove netdata-plugin-ibm netdata-plugin-ibm-libs

Then fix any remaining broken dependencies:

sudo apt --fix-broken install

Then manually update the agent:

sudo /usr/libexec/netdata/netdata-updater.sh