Clean traces, detections & alerts

Traces you don’thave to read

Q: Do detections affect my application?

No. Detections are read-only labels applied to recorded spans. They help people and downstream analysis find relevant behavior without changing how the application runs.

Q: Can neatlogs catch failures that do not produce errors?

Yes. Classifiers and application-specific detections can flag behavior such as irrelevant retrieval, user frustration, missing actions, policy violations, and plausible but incorrect outcomes—even when the workflow completed without an exception.

Q: Do I need to replace my existing tracing platform?

No. You can instrument applications with neatlogs or import traces from supported platforms. This lets you adopt neatlogs for monitoring and investigations without replacing your existing stack first.

Q: What’s the difference between a detection and an alert?

A detection labels an event inside a trace. An alert rule determines when one event, or a pattern across events, deserves a notification.

Q: Can I create detections for my own application?

Yes. You can define detections around the workflows, spans, attributes, patterns, thresholds, and behaviors that matter to your product.

Q: How do detections relate to evals?

Detections surface events and behaviors continuously. Evals apply an explicit rubric to determine whether an agent’s behavior met a quality standard. A failed eval may become a signal worth monitoring; a detection may identify the cases that should be evaluated.

Q: What happens after a detection fires?

You can inspect the triggering span, filter for related runs, monitor its frequency, create an alert, or open the incident in Investigations to determine the cause and prepare a fix.

neatlogs removes the noise, and labels what matters.

Start free Read the docs

Production tracesupport_agent.run

2,846 events · 286 spans6 relevant spans

router.invoke1.2s

load_session42ms

gpt-4.1611 tok

lookup_customer91ms

lookup_customer87ms

lookup_customer89ms

policy_agent2.8s

search_kb404ms

gpt-4.1428 tok

customer_history1.9s

load_orders2.1s

count_delivery_failures2.3s

decide_resolution2.4s

refund_policy2.5s

compose_reply2.7s

render_response18ms

gpt-4.1374 tok

refund_exception_missedFailed

support_agent.runWorkflow24.8s

triage_agentAgent3.6s

lookup_customerTool84ms

customer_historyTool2 delivery failures

gpt-4.1LLM374 tokens

decide_resolutionErrorException missed

Root signalCustomer history was ignored

Two prior delivery failures never reached the refund decision.

6 cited spans

286 spans arrive.neatlogs leaves the evidence.

Every run becomes a clean trace. Open it to see what happened.

Traces

WorkflowDetectionsEvalsLatency＋ More filters

Sep 4Sep 6Sep 8Sep 10Sep 12Sep 14Sep 16

TraceStatusDetectionsEvaluationInput → output

support_agent.run12:57 pm · Sep 16Customer history ignored+6Needs reviewRefund an undelivered order…Refund refused

support_agent.run12:56:41 pm · Sep 12Exception applied+3PassedRepeat delivery failure…Refund approved

support_agent.run12:55:19 pm · Sep 12Policy context missing+4Needs reviewOrder never arrived…Standard policy quoted

support_agent.run12:53:58 pm · Sep 12History used+2PassedThird delivery failure…Refund approved

support_agent.run12:52:14 pm · Sep 12Exception confirmed+3PassedOrder never arrived…Refund approved

16 Sep, 12:57 PM

Support-automation-demo14

Input

Support ticket

Preset: refund_request
Customer: Maya Chen
Email: maya.chen@example.com
Order: NL-10482

Message

My order never arrived. This is the third delivery failure. I would like a refund for the current order.

Customer history

images.unsplash.com

SHOW LESS

Detections⌄　14 STEPS · 24.8SEXPAND ALL

Refund policy selected
Undelivered order loaded
Customer history ignored
Repeat delivery failures found
Exception evidence available
Refund exception missed
Poor judgment

checkout_agent.runWORKFLOW24.8s
route_requestHTTP22.3s
triage_agentAGENT3.0s
lookup_customerTOOL84ms
search_knowledge_base × 9TOOL4.4s
gpt-4.1LLM　374 tok · $0.00493.4s
retrieve_recovery_policyTOOL420ms
decide_resolutionAGENT2.9s

Make traces useful

Raw traces are hard for people to read, and expensive for models to reason over. neatlogs turns them into structured evidence first.

Deduplicate

Collapse redundant instrumentation and repeated calls into one legible execution.

Clean

Extract prompts, responses, tool inputs, and outputs from wrappers and metadata.

Label

Mark broken tools, bad arguments, drift, degraded output, and anything else you define.

Simplify

Surface the spans that affected the outcome, so every investigation starts with the strongest evidence.

One investigation

47 related runs

support_agent.runUndelivered order

refund_agent.runRepeat delivery failure

delivery_history.runRefund refusal

250+ spans

lookup_policyRetrieval

create_refundTool

gpt-5.5 responseLLM

19 labeled spans

Incorrect responseIncorrect

Tool failureFailure

Better outcomeSuggestion

6 relevant spans

lookup_policyEvidence

create_refundEvidence

gpt-5.5 responseEvidence

Search inplain English

Find every refund run where customer history was available but not used.

Ask in plain English, and neatlogs returns the answer with the policy evidence attached.

Ask in Slack

neatlogs# agent-support•••

Mark9:41 AM

@neatlogs Which refund refusals ignored customer history?

neatlogsAPP9:41 AM

12 refund runs match. four refused an exception after customer_history found repeated delivery failures.

The affected runs share the same ignored customer-history path and missed refund exception.

support_agent.run4 refusals

customer_history2 failures

decide_resolutionException missed

Ask in the app

Find refund runs that missed the repeat-delivery exception

Analysis

3 runs match. support_agent.run ignored two prior delivery failures before deciding the refund.

Evidence

support_agent.run24.8s

customer_historyIgnored

compose_replyPoor judgment

Ask anything…All workflows

Ask from the CLI or MCP

support-agent / zsh

$neatlogs askWhich refund refusals ignored customer history?

Searching production across 2,846 traces

12 matching runs found4 need attention

customer_history found two prior delivery failures, but decide_resolution did not use them.

support_agent.run 4 refusalscustomer_history Ignoredrefund_fallback 3 retries

Traces tell you what happened.
Detections show
where to look

Detections are read-only labels attached to the exact span where a condition or behavior appeared

Start with suggested detections

neatlogs finds recurring patterns in imported traces and suggests detections you can accept, edit, or ignore.

northline_support_run

triage_agent

lookup_customer

gpt-5.5-2026-04

resolution_agent

create_refund

02 · Define what matters to you

Create exact-match, regex, threshold, or classifier-based detections for business-specific judgment.

Draft with AI

What do you want to detect?

Flag refund decisions that ignore customer history

Detection createdCustomer history ignored

Active

03 · Alert the right people

Send Slack or email alerts based on severity, frequency, evaluation window, and cooldown, with the evidence attached.

SlackNow

neatlogs · #agent-alerts

High: customer history ignored before refund decision

MailNow

neatlogs alert: customer history ignored

Critical severity · 10 events across 7 runs

04 · Monitor detections

Track frequency, trends, affected workflows, and overlap with failed evals and known incidents.

Customer history ignored

41Flagged spans33PeakLast 3 months

JunJulAug

customer_history

ToolCustomer history ignored

decide_resolution

AgentCustomer history ignored

compose_reply

AgentCustomer history ignored

Repeat refund refusalsFires when customer history is ignored

Severity: Critical
Aggregation: 10 matches
Evaluation: 5 minutes
Cooldown: 30 minutes

Name: Customer history ignored
Decision: Refund refused
Type: Refund policy classifier
Scope: All refund output spans
Evidence: Customer history and policy exception

One system.Four different questions

CapabilityThe question it answers

01Trace

What happened in this run?

02Detection

Where did a known condition appear?

03Eval

Did the behavior meet an explicit standard?

04Investigation

Why did it happen, and what should change?

FAQs01 / 08

What’s the difference between a trace and a span?

A trace is the complete record of one agent task. A span is one operation inside that trace, such as a model call, retrieval, tool invocation, agent handoff, or deterministic function.

FAQs

What’s the difference between a trace and a span?

A trace is the complete record of one agent task. A span is one operation inside that trace, such as a model call, retrieval, tool invocation, agent handoff, or deterministic function.

Do detections affect my application?

Can neatlogs catch failures that do not produce errors?

Do I need to replace my existing tracing platform?

What’s the difference between a detection and an alert?

Can I create detections for my own application?

How do detections relate to evals?

What happens after a detection fires?

Still unsure?

We’ll look at your stack with you.

Get in touch

Traces you don’thave to read

Every run becomes a clean trace. Open it to see what happened.

Support ticket

Message

Customer history

Make traces useful

Deduplicate

Clean

Label

Simplify

Search inplain English

Hello, John

Evidence

Traces tell you what happened.
Detections show
where to look

Start with suggested detections

02 · Define what matters to you

What do you want to detect?

03 · Alert the right people

neatlogs · #agent-alerts

neatlogs alert: customer history ignored

04 · Monitor detections

Customer history ignored

Bring the tracesYou already have

One system.Four different questions

What’s the difference between a trace and a span?

FAQs

Still unsure?