Get support
Send a reproducible, safe support request with the identifiers needed to investigate quickly.
The fastest support request identifies the affected object, exact time, visible symptom, and last known working comparison without exposing secrets.
Choose the support channel
Email neatlogs-support@neatlogs.com, or use the channel named in your onboarding material or commercial agreement. The same address appears in Neatlogs emails, so you can also reply to one of them. The dashboard does not have a separate support form.
For suspected security vulnerabilities or data exposure, use the private security path in your agreement if you have one. Otherwise, email support, mark the message as security sensitive, and describe the issue without including the exposed data. Do not post sensitive reports in a public issue or shared channel.
Include the right identifiers
Start with:
- organization name and region (US or EU);
- project name and project ID;
- affected trace, session, Eval, detection, alert, or incident ID, or the integration or import source;
- exact timestamp and timezone;
- workflow and environment;
- integration, SDK, runtime, and version;
- exact error message and HTTP status;
- last successful comparable action;
- concise reproduction steps.
Use screenshots only when they capture state that IDs, timestamps, and logs do not.
Describe the problem in a reproducible form
Impact: Production traces stopped arriving for checkout-agent.
Project: Checkout production (US region), project ID included.
Started: 2026-08-21 14:10 IST.
Last success: 2026-08-21 14:07 IST.
Runtime: Node.js version and Neatlogs SDK version included.
Observed: Exporter returns HTTP 401.
Reproduction: Run one checkout test with the production deployment key.
Checked: Project, time range, initialization, and key presence.
Doctor: local mode passes; probe mode fails with AUTH_FAILED.Separate observed facts from suspected cause.
Remove secrets and unnecessary personal data
Never send:
- API or provider keys;
- OAuth tokens;
- passwords;
- authorization headers;
- private keys;
- complete sensitive trace payloads;
- customer data unrelated to the problem.
Start with object IDs. Authorized support staff can use controlled systems to locate evidence when permitted.
If support requests an export, confirm the approved secure transfer path first.
State impact and urgency
Explain whether the problem:
- blocks all ingestion or one workflow;
- affects one project or several;
- risks data exposure;
- prevents review or investigation;
- causes incorrect automated action;
- is a usability problem with a workaround.
Urgency should reflect impact, not the number of retries already attempted.
Preserve diagnostic evidence
Before reconnecting, restarting, or rotating:
- save the original error;
- record timestamps and object IDs;
- note the last successful attempt;
- avoid deleting failed jobs or rules;
- avoid repeated writes when duplication or side effects are possible.
Tell support which troubleshooting steps have already been completed.
Frequently asked questions
Should I send a full trace export?
Start with the trace ID. Send an export only through an approved secure channel when requested.
Where should I report a suspected vulnerability?
Use the private security reporting path in your agreement. Without one, email neatlogs-support@neatlogs.com, mark the message as security sensitive, and leave the sensitive data out.
What if I cannot access the project ID?
Provide the organization, project name, region, affected URL, timestamp, and signed-in account identifier.
Should I retry before contacting support?
Use the relevant troubleshooting page and preserve the original error. Avoid repeated imports or external writes when duplication is possible.
What makes a good last-working comparison?
A run, job, or connection from the same project, workflow, environment, and configuration that succeeded shortly before the failure.