Troubleshooting: I see no data

Work top-down. First figure out which path you're on — agent (Kubernetes, Docker, or Linux server source) or OpenTelemetry (service source) — then jump to that section.

First checks (every path)

Scope. The source switcher at the top of every page scopes what you see. Set it to All sources (or the right one) — you may be looking at the wrong scope.
Time range. Widen it. If you just started sending data, the default window may predate it.
Source status. On the Sources page, is the source CONNECTED / OTLP RECEIVING (green), or DISCONNECTED / no data yet?
Agent advisories. Open Infrastructure for the source. An amber *"This agent is collecting less than you asked for"* banner usually names your problem outright — a glob matching nothing, a file cap reached, journald unavailable. Check it before reading any logs. See Reading infrastructure status.

Agent path (Kubernetes / Docker)

Source stuck on DISCONNECTED / "no data yet"

The agent isn't reaching the server. On the node(s):

# Kubernetes
kubectl -n observekit get pods -l app=observekit-agent
kubectl -n observekit logs -l app=observekit-agent --tail=100
# Docker
docker logs --tail=100 observekit-agent

Look for:

RBAC denials (forbidden, cannot list pods) → the ClusterRole/Binding didn't apply. Re-run the install command; confirm you had permission to create cluster-scoped RBAC.
Connection refused / timeout / TLS errors → the cluster can't reach the server. Confirm outbound HTTPS egress and DNS to observekit-api.expeed.com from the node.
No agent pods at all → kubectl -n observekit rollout status daemonset/observekit-agent; check node taints/tolerations if pods aren't scheduling.

Connected, but a specific namespace/pod's logs are missing

The agent filters at collection time. Check the ConfigMap:

kubectl -n observekit get configmap observekit-agent -o yaml

kube-system and pods labelled observekit/ignore: "true" are excluded by default. Confirm your namespace/label/container isn't caught by a filter, and watch for drops:

kubectl -n observekit logs -l app=observekit-agent --tail=50 | grep -i filter

> A filter that "isn't working" is usually an indentation typo — a mis-indented key is ignored as an unknown field, so the rule you thought you wrote is simply not there. A genuinely malformed file is different: it stops the agent at startup rather than being skipped, so look for a CrashLoopBackOff, not for missing data. See Agent configuration.

Linux server / VM source

Source stuck on PENDING

systemctl status observekit-agent
journalctl -u observekit-agent -n 50

Most often outbound HTTPS is blocked, or the API key was never written — check /etc/observekit/agent.env exists and is mode 0600.

Connected, host metrics fine, no logs

Two causes, in order of likelihood:

Nothing is configured to be collected. This is the default and the commonest answer. Unlike Kubernetes and Docker, a host agent discovers nothing — it tails only the files named in host.log_files. See Host mode.

The agent cannot read them. It runs unprivileged and reads logs through two group memberships:

```bash

id observekit # must list adm and systemd-journal

```

If either is missing the installer said so and carried on, and the message has long since scrolled past. Fix and restart — a group change does not affect a running process:

```bash

sudo usermod -a -G adm,systemd-journal observekit

sudo systemctl restart observekit-agent

```

Some log sources arrive, others don't

Open Infrastructure for this source and read the Log sources list on the host's card: it shows each configured source and how many entries it produced in the last hour. A source with no entries, or absent entirely, is a glob matching no files — check the path for a typo. The advisories banner usually says so explicitly.

Journald configured but nothing arrives

journalctl is not installed, or the observekit user is not in systemd-journal. The advisories banner names the first case directly.

OpenTelemetry path (service source)

Read your app's logs for OTLP exporter errors first — the SDK reports the exact HTTP status. Then match it below.

401 Unauthorized

The API key isn't reaching the server.

Confirm the header: X-API-Key: <key> or Authorization: Bearer <key>.
Watch the header form — a common mistake is X-API-Key=Bearer <key> (the word Bearer ends up inside the key value). Use one scheme, not both.
Confirm the key matches a source on this server (keys are per-source and environment-specific).

400 Bad Request / "unable to parse"

The body couldn't be decoded.

Endpoint path. Point the SDK at the base URL (https://observekit-api.expeed.com) and let it append /v1/traces etc. Don't hard-code the wrong path or protocol.
Protocol vs. port. Use http/protobuf for the HTTPS URL (port 4318). Port 4317 is gRPC — only use it with protocol=grpc.
Compression. gzip and zstd are supported. (If you're on an older ObserveKit server that rejected gzip, upgrade the server — current versions decompress it.)
Body too large. The per-request cap is 10 MiB. If you send huge batches, lower the SDK's max export batch size.

Source stuck on "no data yet" / "OTLP idle" though the app started

The SDK batches — most flush every ~5s. Generate traffic and wait one interval.
Confirm the app can actually reach observekit-api.expeed.com:443 (egress/DNS/proxy).
Check the app logs for exporter errors (connection refused, DNS failure).

Data arrives but the service shows as `unknown_service`

Set OTEL_SERVICE_NAME (or the service.name resource attribute). Many SDKs default to unknown_service when neither is set — so your data is there, just under the wrong name. Filter the Traces/Logs views by service.name.

Still stuck?

Send a manual OTLP smoke test to isolate app-vs-server: a single POST /v1/logs with your key and a tiny OTLP JSON body should return 200 {}. If the smoke test works but your app doesn't, the problem is in the app's OTel config, not ObserveKit. See Sending data with OpenTelemetry.
Verify the key maps to the source you're viewing (an OTel app can only land data in the source its key belongs to).