Search across production

Search across production when the question is larger than one known trace.

You may have a customer report without a trace ID, a detection spike with no obvious cause, or one failure that might affect many workflows. The goal is not a plausible summary. It is a confirmed set of runs that answers a scoped question.

Plain-language production search happens in investigate in the sidebar: a Neatlogs AI chat that searches and reads the traces in your active project, runs read-only analytics queries over them, and links its answers back to the traces and spans it used. Anyone with access to the project can use it.

Decide whether you need filtering or investigation

Use deterministic filters before a plain-language question when you already know the exact field.

Turn the report into a search question

Suppose support reports: “Some customers saw payment failed even though the payment completed.”

A useful search question defines three parts:

Find checkout-assistant runs in production from the last 24 hours
where the payment tool succeeded but the final answer said payment failed.

Avoid “find checkout problems.” It leaves the system to invent both the population and the definition of a problem.

Search in four passes

1. Establish the scope

Open investigate and confirm the active project. A chat searches one project; it cannot reach other projects.

Below the input, set the scope chips before you ask:

• the workflow chip (All workflows until you choose one or more workflows);
• the date chip, which defaults to the last 14 days. Choose 14 days, 30 days, 3 months, Any time, or a custom range.

The chips apply to every question you send in the chat. Name other stable dimensions in the question itself, such as environment, end user, session, model, tool, detection, or release tag. Use Attach files from the + menu to add a support export or screenshot when it defines the population.

Start near the reported incident. Expand only when you need a baseline, recurrence history, or more comparison cases.

2. Ask for the behavior

Describe the relationship that matters, not only a keyword. “Tool succeeded but final answer reported failure” is more precise than searching for the word “payment.”

A strong query defines the population and the behavior that separates a match from a normal run.

3. Open the returned evidence

Answers link to the traces and spans they rely on, and each link opens in a new tab. When an answer returns a table, it opens in a side panel with a Trace ID column and Export CSV.

Review a small set before refining the query:

• one clear match;
• one near miss;
• one successful run from the same workflow;
• one result from a different slice if the search spans models or releases.

Confirm that each result matched for the intended reason. Shared words, generic error text, or reused metadata can produce misleading candidates.

4. Refine one dimension at a time

Follow-up questions retain the thread context. Use them to narrow or compare without changing several assumptions at once.

Compare those failures with successful runs from the same workflow,
model, and release.

Which span is the earliest consistent difference between the two groups?

Do the failures affect one customer cohort or all checkout traffic?

Follow-up questions keep the established scope, but every important conclusion should still link to inspectable evidence.

If the chat grows too long for the model to continue, start a new chat and restate the scope and the confirmed traces.

Separate findings from explanations

A search can establish:

• where the behavior occurred;
• how often it appeared in the searched population;
• which slices are affected;
• which runs are useful comparisons;
• where executions appear to diverge.

It does not automatically prove a root cause. “All failures used model X” is not causal if all successful runs also used model X.

Treat an uncited summary as a hypothesis. A material claim should lead to traces or spans that support it. Counts from a chat come from the samples and queries it ran, so ask how many runs it examined before you treat a rate as the whole population.

Keep the thread and turn the finding into work

Chats are saved automatically in your chat history (the chats tab in the sidebar, or New chat to start over). They are private to you in that project and cannot be shared, so copy the question, the scope, and the trace links when you hand the finding to someone else.

When the confirmed finding represents actionable work, record:

• the original question and scope;
• representative matches and controls;
• observed and expected behavior;
• affected workflows, releases, or cohorts;
• impact and known uncertainty.

Then choose the next step:

• Find the cause. Ask the chat to investigate a specific confirmed trace. When the investigation reports a finding, Track as issue adds it to Incidents. See Investigate a failure.
• Watch for recurrence. Ask the chat to draft a detection from the rule you confirmed. Review its preview, which shows sample matches from your data; nothing is created until you select Approve and create, which activates the detection.
• Add to existing work. If an incident already covers the behavior, add the evidence as a comment on it.

Neatlogs creates incidents from production evidence and investigation results; there is no form for creating one by hand. Start an investigation before prescribing a fix when the cause is not yet supported.

Author a detection or alert from AI Search

AI Search can turn a well-scoped conversation into a monitoring draft. Ask it to create a detection for a repeatable behavior or an alert for a response threshold. The draft opens in an artifact canvas beside the conversation so you can review configuration without losing the search context.

For a detection draft:

1. review the proposed scope, type, and condition;
2. preview or retest it against representative traces;
3. correct false matches and missed cases;
4. save the draft, then approve or activate it when the evidence is sound.

For an alert draft, confirm the underlying detection or metric, threshold, window, severity, destinations, and cooldown. Saved alert versions remain available so you can recover the last known configuration if a later edit or activation fails.

Know when the search is complete

You should be able to state:

1. exactly which population was searched;
2. what counted as a match;
3. which traces confirm the finding;
4. how broad the behavior appears to be;
5. what remains unknown.

If you cannot name representative traces, refine the search. If you have enough evidence to explain the problem but need a cause, continue with an investigation.

Frequently asked questions

Is plain-language search the same as a detection?

No. Search answers a current question. A detection continuously evaluates a defined condition. investigate can draft a detection for you, but it is created only after you approve the preview.

What can investigate read?

Traces, spans, and sessions in the active project, detections, Eval results, and read-only analytics queries over project data. It can also use apps you connected yourself under Settings → Account → Tools & MCP, with your own account's permissions. Those actions are read-only unless you explicitly ask for a change in a connected GitHub repository. Custom MCP servers are not used by investigate. See Tools and MCPs.

Which model answers?

Neatlogs Fast by default. Use the model picker to choose Neatlogs Pro, or a model from a provider key added under Settings → Project → AI Providers. See Model providers.

Why did search miss an imported run?

Check the target project, the date chip, source mapping, and whether the imported fields contain the searched content.

Can I search across projects?

No. Each chat is scoped to the active project. Switch projects and ask again when evidence is intentionally isolated.

Should I search all history immediately?

Usually not. Start with the incident window, confirm the behavior, then widen the date chip to measure recurrence or find controls.

Next step

Investigate the confirmed finding →