The whole production story, from one terminal

There is a familiar little journey behind almost every production question.

You start with the logs. They tell you what the application said, but not whether it happened once or a thousand times. So you open a metrics dashboard. The graph shows the shape of the problem, but not the request that took the strange path. Then you open tracing, find the service, rebuild the time window, and try to remember which environment you were looking at in the first place.

Today we’re making that journey much shorter. Watasu CLI 0.1.10 can query your app’s metrics and traces directly, alongside the logs you already read there.

Same app. Same access controls. Same terminal. Three different ways to understand what it is doing.

Ask the graph a question

watasu metrics accepts PromQL, so a quick health question can stay quick:

watasu metrics --app my-api --query 'sum(up)'

PromQL arrives intact at the metrics store attached to your app. That means this is not a tiny collection of pre-selected charts: you can aggregate, group, filter, and use the functions you already know.

# Requests per second, grouped by status
watasu metrics --app my-api \
  --query 'sum by (status) (rate(http_requests_total[5m]))'

# The last six hours, one point per minute
watasu metrics --app my-api \
  --query 'sum(rate(http_requests_total[5m]))' \
  --since 6h \
  --step 60

Without --since, the command runs an instant query. Add a duration and it becomes a range query ending now; --at lets you ask about another instant. The normal output is a compact tab-separated summary that behaves nicely in a shell, while --json keeps the complete backend response for scripts and deeper inspection.

Follow one request all the way through

Metrics are wonderful at telling you that something changed. Traces answer the next question: which request, and where did its time go?

watasu traces speaks TraceQL:

watasu traces --app my-api \
  --query '{ status = error }' \
  --since 30m \
  --limit 20

Once you have the trace you care about, fetch the complete thing by ID:

watasu traces --app my-api --trace-id 4f3c2a1b...

The default view keeps the useful landmarks readable — trace, service, operation, duration, and status. --json preserves the full trace and its spans when you want to pipe it into another tool or let an agent investigate it.

Together, the loop becomes pleasantly direct:

watasu logs    --app my-api -q '|= "timeout"'
watasu metrics --app my-api -q 'sum(rate(request_timeouts_total[5m]))'
watasu traces  --app my-api -q '{ status = error }' --since 30m

Read what happened, measure how often, then follow the request — without losing the app you were asking about between tabs.

The app is the boundary

The nicest part is what the commands do not ask you for. There is no VictoriaMetrics URL to copy, no Tempo credential to export, and no cluster service address to know.

The CLI resolves the app exactly as other Watasu commands do: from --app, from --remote, or from the watasu Git remote in the current repository. Watasu authorizes your existing app access, finds the ready metrics or traces add-on attached to that app, and queries only that tenant’s backend.

If the app does not have the relevant add-on, the command simply says so. If it does, the query travels through a short-lived authenticated connection and the connection disappears with the request. Backend addresses and credentials never arrive in the CLI.

We also put guardrails around the tempting queries: requests are rate-limited per user and app, and range queries have a point ceiling so an accidental tiny step over a long window cannot turn one terminal command into a very large surprise. Bad PromQL or TraceQL comes back as a useful query error; failures in our own transport are reported to our incident tracking so they are ours to notice and fix.

It is the boring plumbing underneath a very small command — exactly where boring plumbing belongs.

Available now

Metrics and traces ship in Watasu CLI 0.1.10 for every app with the corresponding monitoring add-on attached.

brew upgrade watasu
watasu metrics --app my-api --query 'sum(up)'

The CLI docs cover all options, and the observability docs walk through logs, metrics, and traces together.

We like dashboards. We also like staying in the terminal long enough to answer one question while it is still the question we meant to ask. Now you can do both.

Happy querying — and if there is one more production question you wish were a command, tell us at info@watasu.io.