Verify your data arrived

How to tell the difference between accepted and queryable, the three places to look, and what each failure at each stage actually means.

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.

Before you start. You need a license key and something sending data — a collector, an SDK, or the curl below.

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 queue 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.

Get Started in the dashboard shows the exact base endpoint for your deployment next to a license key you create there, with copy buttons, and then watches for your first records. Where these pages write $OIQ_ENDPOINT, that page has the real value.

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.

A timestamp far in the past may be dropped, not stored. Records are retained for a fixed window per plan. One stamped before that window opens is outside retention on arrival, so it is accepted and then not queryable — which reads exactly like a broken pipeline. If you are pasting an example from anywhere, replace the timestamp.

Expected: HTTP/1.1 202 Accepted.

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

Code	Meaning
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

A live check of whether this workspace has received anything at all. The fastest way to distinguish “nothing has ever arrived” from “something arrived but not what I expected”.

Services

Every distinct service.name seen recently. A service missing here that you believe is running usually means the resource attribute is not being set.

Overview

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 table 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.

Next

Search your logs

The query syntax.

Set up alerting

Alert on what you are now collecting.

Nothing showed up

Stage-by-stage diagnosis.