> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/get-started/license-keys) 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.
```bash theme={null}
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](/send-data/endpoints#status-codes). 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:
```text theme={null}
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:
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".
Every distinct `service.name` seen recently. A service missing here that you
believe is running usually means the resource attribute is not being set.
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:
```bash theme={null}
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](/support/troubleshooting) works
through the pipeline stage by stage.
## Next
The query syntax.
Alert on what you are now collecting.
Stage-by-stage diagnosis.