Natural-language search

Ask CloudWatch in English. Get an answer, not a query.

Logs Insights syntax is fine — once a quarter. The other 99% of the time you just want to know how many 5xx users-api threw in the last 30 minutes. Type that. We translate it, run it, and explain what came back.

Radar tracking a scent — nose to the ground

What you'll actually see

search · acme-api · last 30m

you asked

"How many 5xx did users-api throw in the last 30 minutes, grouped by route?"

generated · logs insights
fields @timestamp, @message, route, status
| filter status >= 500 and status < 600
| filter ispresent(route)
| stats count(*) as errors by route
| sort errors desc
| limit 20

result · 4 routes hit

route	errors
POST /v1/jobs	487
POST /v1/payments/charge	412
GET /v1/sessions	23
POST /v1/coupons/apply	4

Plain-English summary: Two routes account for 96% of the 5xx — both go through PaymentProcessor.charge. This pattern lines up with deploy v3.42.1 from 14:19. See INC-2041.

What changes for the on-call engineer

Zero query memorization

New on-callers ramp in days, not quarters. The hard part of CloudWatch is gone.

Always explained

Every result ships with a plain-English summary. The numbers come with meaning.

Copyable to Logs Insights

We show the generated query — paste it into AWS if you want to keep tinkering.

How it works

step · 01

Type a question

English. The looser the better — we'll pick the right log groups from your service map.

step · 02

We translate

Your question becomes a real Logs Insights query. We run it against the live log groups.

step · 03

Read the answer

Get the table back with a one-paragraph summary that ties it to recent deploys and incidents.

Pairs well with

Trace journey

Same data — but for a single ID across services.

Service map

Why we know which log groups your question is about.

Resolve incidents in 30 seconds, not 30 minutes.

Connect your AWS account in read-only mode and let Radar take the next page.