Verify your data arrived

The most common reason a first install looks broken is that it is not: the request was accepted, and the reader is looking somewhere that has not caught up yet, or filtering to a window the data does not fall in.

This page separates the two questions — *did it arrive* and *can I see it* — because they fail for different reasons and have different fixes.

Accepted is not the same as queryable

A successful ingest request returns 202 Accepted. That means the batch was published to the pipeline. It does not mean the data is in a table yet.

Between the two there is a Kafka topic and a batching consumer, which flushes when it has 50,000 rows or after five seconds — whichever comes first. On a quiet first install, the five seconds is what you are waiting on.

So the expected sequence for a new install is:

1. 202 from the receiver, immediately.
2. The record queryable, typically within a few seconds.
3. Rolled-up metric views (the 1-minute and 1-hour tables the charts read for wide time ranges) populated on their own schedule.

If you send one span and immediately open a dashboard set to "last 24 hours" rendered from hourly rollups, an empty chart is the correct answer for a short while. Narrow the range to the last 15 minutes before concluding anything.

Step 1 — send something you can recognise

Send a log line with a service name nothing else uses. Replace the base URL with the one shown on Get Started in the dashboard, and the key with your own.

curl -i -X POST "$OIQ_ENDPOINT/v1/logs" \
  -H "X-License-Key: $OIQ_LICENSE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "resourceLogs": [{
      "resource": {
        "attributes": [
          { "key": "service.name", "value": { "stringValue": "verify-check" } }
        ]
      },
      "scopeLogs": [{
        "logRecords": [{
          "timeUnixNano": "'"$(date +%s)000000000"'",
          "severityText": "INFO",
          "body": { "stringValue": "verification probe" }
        }]
      }]
    }]
  }'

timeUnixNano is built from the current clock on purpose. A hardcoded timestamp is the single most common reason a test record is accepted and then cannot be found: it lands wherever that timestamp falls, which may be years outside the window you are searching.

Expected: HTTP/1.1 202 Accepted.

Anything else is an ingest-side problem and the status code says which one — see Ingest endpoints and errors. The short version:

• 401 — the key is missing, malformed, or revoked.
• 403 — the key is valid but the signal is not enabled for the plan.
• 413 — the batch is over the size cap; send fewer records per request.
• 429 — rate limited; back off and retry.

Step 2 — find it in the product

Open Logs and search for the service name you used:

service.name:"verify-check"

Set the time range to the last 15 minutes. If it is there, the pipeline works end to end and anything else you are missing is a configuration question about the sender, not about ingest.

Three other places answer the same question from different angles:

• Get Started shows a live check of whether this workspace has received anything at all. It is the fastest way to distinguish "nothing has ever arrived" from "something arrived but not what I expected".
• Services lists every distinct service.name seen recently. A service missing here that you believe is running usually means the resource attribute is not being set — see below.
• Overview shows ingest volume over time, which tells you whether data is arriving continuously or arrived once and stopped.

Step 3 — if the collector is in the path

When an OpenTelemetry Collector sits between your services and aiAxonIQ, it can accept spans from your app and still fail to export them. Its own metrics distinguish the two:

curl -s localhost:8888/metrics | grep -E 'otelcol_(receiver_accepted|exporter_sent|exporter_send_failed)'

• otelcol_receiver_accepted_* climbing — your app is reaching the collector.
• otelcol_exporter_sent_* climbing — the collector is reaching aiAxonIQ.
• otelcol_exporter_send_failed_* climbing — it is trying and being refused. Its logs carry the status code, which maps to the list above.

Accepted rising while sent stays flat is the classic signature of a wrong endpoint or a missing key in the exporter block, and it is worth checking before anything else, because from inside your application everything looks fine.

What "no data" usually turns out to be

In rough order of frequency:

1. The time range. Narrow it to 15 minutes before believing an empty chart.
2. A hardcoded timestamp in a copied example.
3. The base URL. A self-hosted deployment behind the bundled nginx serves OTLP under /otlp and strips the prefix; a hosted one does not. The value on Get Started is the one this deployment actually serves.
4. No service.name. Records without it still arrive, but they will not appear under any service, which is where most people look first.
5. Signal not enabled for the plan — a 403 that a fire-and-forget exporter swallowed without logging.

If none of those apply, Troubleshooting works through the pipeline stage by stage.