Traces are not arriving
Follow the trace path from project key and initialization through export, ingestion, and dashboard scope.
When no trace appears, locate the first broken step:
Application creates spans
↓
Neatlogs initializes with a project key
↓
Exporter sends a completed batch
↓
Network and regional endpoint accept it
↓
Project receives and processes it
↓
Dashboard scope includes itUse one distinctive test run and record its timestamp before changing configuration.
1. Run SDK Doctor
SDK Doctor separates SDK problems from application problems. Run it from the application root before editing instrumentation:
- Local mode (
doctor --local) needs no key and no network. It proves the installed SDK can capture, mask, and flush a controlled trace. - Probe mode (
doctor --probe) usesNEATLOGS_API_KEYfrom the environment. It sends one controlled trace through the normal write path and reads that exact trace back.
python -m neatlogs doctor --local --json
python -m neatlogs doctor --probe --jsonSee SDK Doctor for the TypeScript and Go commands.
If the probe passes but your application's traces are missing, the problem is in your application's initialization, code path, or shutdown, not the key or endpoint. If it fails, read first_failure and the reason-code guide. Doctor does not check your own instrumentation or import order.
2. Confirm the destination project and region
The ingestion key determines the project. The dashboard project currently open does not change where telemetry was sent.
Check:
- organization and project selected in the workspace switcher;
- key used by the running deployment;
- region: a project created at
https://eu.app.neatlogs.comneeds the EU ingest endpoint; - the Workflow, Tags, and Metadata filters in the trace list;
- the time range (the trace list defaults to Last 14 days, in your browser's timezone).
Clear filters and include enough time for delayed export or a long-running execution. The Status filter shows whether a trace is Processing, Ready, or Processing failed.
For a brand-new project, the setup page checks for the first trace automatically and shows Waiting for first trace until one arrives.
3. Confirm the key and endpoint are available
For SDK setup, verify that the expected environment variable or explicit key is present in the actual runtime, not only in a local shell.
export NEATLOGS_API_KEY="your-project-api-key"
# EU projects only:
export NEATLOGS_ENDPOINT="https://eu.ingest.neatlogs.com"import neatlogs
neatlogs.init(debug=True)With debug logging enabled, a missing key reports that HTTP export is disabled while the application continues running. Without debug logging, that message is not shown.
Server-side SDKs need the project API key or a project ingest credential. A browser write key (nlw_) only works with the Browser SDK and POST /v1/trace; SDK export rejects it with 401.
Never print the complete key. If it may have been exposed, see Understand project keys.
4. Check initialization order
In Python, call neatlogs.init() before importing libraries listed in instrumentations=[...]. Python wrap() and the TypeScript SDK have no import-order rule. No SDK warns when the order is wrong.
For explicit wrappers:
- confirm the application uses the wrapped client;
- confirm the executed code path reaches the instrumented operation;
- avoid creating an unwrapped second client later.
Create one explicit test span when you need to distinguish export failure from unsupported automatic instrumentation.
5. Let the run complete
Exporters buffer spans. A short-lived script can exit before the final batch is sent.
Confirm:
- the root operation finishes;
- spans close cleanly;
- the SDK flush or shutdown path runs;
- serverless and worker runtimes allow export time;
- errors do not terminate the process before cleanup.
Python and TypeScript register exit handlers by default. Go does not: call the shutdown function returned by Init (or neatlogs.Flush) before the process exits. See Flush and shutdown.
Several partial roots can indicate that no explicit workflow root surrounds the complete request or that context propagation was lost.
6. Check the endpoint and network
Inspect debug or exporter logs for:
- authorization errors, including a key from the other region;
- DNS or TLS failures;
- proxy and egress restrictions;
- connection timeouts;
- retries;
- an incorrect custom endpoint (use the base URL, such as
https://eu.ingest.neatlogs.com, without a path); - OTLP protocol or port mismatch for raw OpenTelemetry exporters.
Test from the same runtime or network as the application. A request working on a laptop does not prove production egress works.
7. Check what the SDK drops on purpose
Spans can be dropped before export by configuration:
NEATLOGS_DISABLE_EXPORT(ordisable_export) turns export off;- a
sample_ratebelow1.0exports only some traces; - a
maskcallback that raises or times out drops the affected item rather than exporting it unmasked (in TypeScript and Go, returning null or nil also drops it).
8. Check instrumentation coverage
If explicit spans arrive but model or tool spans do not:
- confirm the installed integration supports the library and version;
- in Python, initialize before importing auto-instrumented libraries;
- check whether the failing path uses a different client;
- verify framework-specific instrumentation settings;
- check whether a
maskcallback dropped the span, or server-side redaction removed content.
Use the relevant SDK Reference or Integration page for canonical setup.
Diagnose by symptom
| Symptom | Likely area |
|---|---|
| Doctor local fails | Installed SDK version or environment |
| Doctor probe fails with an authentication error | Project key, region, or endpoint |
| Doctor probe passes, application traces missing | Initialization, code path, or shutdown |
| Nothing arrives and no exporter logs appear | Initialization, code path, or disabled export |
401 from ingest | Wrong key, key from the other region, or a browser write key in a server SDK |
| Explicit span arrives but automatic spans do not | Integration coverage or Python import order |
| Last trace from a script is missing | Flush or shutdown |
| One request appears as several traces | Context propagation or missing root |
| Trace exists but model/tool content is absent | Instrumentation coverage, masking, or redaction |
| Trace shows Processing failed | Ingest processing; contact support with the trace ID |
| Trace is in another project | Wrong deployment key or write-key project name |
Frequently asked questions
Why is there no application error when the key is missing?
The SDK lets the application continue with export disabled. Enable debug logging during setup, or run Doctor probe mode.
Why do scripts lose their last trace?
The process may exit before a buffered batch is exported. Flush or shut down cleanly.
Why do I see several partial traces?
Create one explicit workflow root and propagate its context across services and workers.
What should I send support?
Project ID, test timestamp and timezone, region, SDK and version, workflow, runtime, debug output, endpoint type, the Doctor JSON result, and whether an explicit test span appeared. Never send the full key.
