The agent is installed but no data appears

You ran the install command, the server is in the dashboard, and nothing arrives: the server shows Stale or Offline (or Needs attention because its Agent offline rule fired), or its page says “No historical data available” or “Metrics will appear once the agent starts sending data.” Whether monitorable-agent.service is running or not, the checks below find the cause on the affected server, ordered by how often each turns out to be it. (If just one panel is empty while the rest draw normally, that’s A panel is missing or empty, not this page.)

Give a fresh install 60 seconds

The agent sends its first batch about a minute after monitorable-agent.service starts, and the dashboard draws points shortly after they arrive. If you ran the install command less than a minute ago, this is the whole explanation.

Check the service is running

systemctl status monitorable-agent

Healthy looks like Active: active (running). A stopped agent looks like:

○ monitorable-agent.service - Monitorable agent
     Loaded: loaded (/etc/systemd/system/monitorable-agent.service; enabled; preset: enabled)
     Active: inactive (dead) since Sat 2026-07-11 09:15:03 UTC; 14ms ago

Start it and confirm it stays up:

systemctl start monitorable-agent
systemctl is-active monitorable-agent

If the service is missing entirely (Unit monitorable-agent.service could not be found), the agent isn’t installed on this server — run the install command.

A running service does not by itself mean data is flowing: delivery failures don’t stop the service. The remaining checks read the logs:

journalctl -u monitorable-agent -f

The logs say “Exporting failed. Will retry the request after interval.”

info  internal/retry_sender.go:133  Exporting failed. Will retry the request after interval.
{..., "error": "failed to make an HTTP request: Post \"https://ingest.monitorable.net/v1/metrics\":
dial tcp: lookup ingest.monitorable.net on 1.1.1.1:53: no such host", "interval": "6.930527828s"}

The agent can’t reach the ingest endpoint — DNS failure, blocked outbound HTTPS, or a proxy in the way. It retries with backoff and keeps recent batches queued, so metrics resume on their own once the network path works. Confirm reachability from the server:

curl -s -o /dev/null -w '%{http_code}\n' https://ingest.monitorable.net/v1/metrics

405

405 is the healthy answer — the endpoint is reachable and answering (it just doesn’t accept a plain GET). A DNS or connection error from curl means the server’s outbound path is the problem, not the agent.

The logs say “Exporting failed. Dropping data.” with HTTP Status Code 401

error  internal/queue_sender.go:50  Exporting failed. Dropping data.
{..., "error": "not retryable error: Permanent error: rpc error: code = Unauthenticated
desc = error exporting items, request to https://ingest.monitorable.net/v1/metrics
responded with HTTP Status Code 401", "dropped_items": 194}

The endpoint rejected the agent’s API key, and this is not retried — each batch is dropped. Two common ways to get here:

• The key doesn’t match the server row in the dashboard (a hand-edited or copy-pasted-from-another-server key).
• The server was removed in the dashboard. Removing a server revokes its API key, so an agent still running on that server gets 401 from then on.

The fix is a fresh key: remove the server in the dashboard if it still exists (Server actions → Remove on its row), add it again, and run the new install command from the dialog. Re-running the install with the new key replaces the stored one.

The logs say “Exporting failed. Dropping data.” with HTTP Status Code 404

error  internal/queue_sender.go:50  Exporting failed. Dropping data.
{..., "error": "not retryable error: Permanent error: rpc error: code = Unimplemented
desc = error exporting items, request to https://app-api.monitorable.io/v1/metrics
responded with HTTP Status Code 404", "dropped_items": 194}

The agent is posting to an address that doesn’t serve ingest — a hand-edited endpoint (in the example above, the dashboard’s API host), or an agent installed before an endpoint change. Reinstall with a current install command: get it from the dashboard by removing and re-adding the server, then run it as root. The install rewrites the endpoint the service uses.

Get told next time the agent goes quiet

The Agent offline rule is on by default on every alert template: it fires when a server’s last report is older than 5 minutes (the rule’s window, which is also the minimum) and sends one notification instead of the usual three, since a server that went offline only needs saying once. It is the one rule that fires without data arriving, so it covers every case on this page. Its window and channel are changed in the template, following Set up one alert.

Still stuck

Collect the last minutes of agent logs:

journalctl -u monitorable-agent --since "-10m" --no-pager

and note your server’s status in the dashboard (Stale or Offline vs. Healthy with empty panels). Those two together identify almost every remaining case. If they don’t, email them to hello@monitorable.io — the logs above contain no API key, so they are safe to paste as-is.

If an incident’s timeline shows Monitorable not receiving, the gap was on our side, not your server’s.