Monitoring

Monitoring

Every request to your Keel app generates a trace. The Monitoring page shows these traces so you can debug errors, find slow queries, and understand what's happening in production.

Works locally too—run keel run and check Local project in the Console.

Dashboard

The top of the page shows four metrics for the selected time range:

MetricWhat it tells you
RequestsTotal API calls
Error ratePercentage that failed
Avg durationTypical response time
P99 durationSlowest 1% of requests

Each metric shows a comparison to the previous period. If error rate is climbing or P99 is way higher than average, you've got something to investigate.

Request list

Below the dashboard you'll see recent requests: status (green/red dot), HTTP method, path, duration, and timestamp. Click any request to see its trace.

Filtering

Click the filter icon to narrow down:

  • Errors only — Hide successful requests
  • API — Filter by API name
  • Action — Filter by specific action
  • API type — JSON, GraphQL, or RPC

You can also paste a request ID directly into the search field to jump to a specific trace.

Reading a trace

A trace breaks down everything that happened during a request. The timeline shows each span—a unit of work like handling the HTTP request, running a function, or executing a database query.

  • Horizontal bars show relative duration
  • Nesting shows parent-child relationships
  • Red indicates errors
  • Click any span to see details

Span details

When you click a span:

  • Attributes — Context like HTTP status, user ID
  • Query — The actual SQL (for database spans)
  • Logs — Output from console.log() in your code
  • Error — Message and stack trace if something failed

Look for the small log icon on spans—that's where the useful debugging context usually lives.

Debugging errors

Filter to errors only, find a failing request, and open its trace. Look for the first red span—that's usually where the problem started. Check the error message, stack trace, and any logs in surrounding spans.

Calling console.error() in your code shows up in traces, so add context when handling errors.

Debugging slow requests

Open a slow trace and look at the timeline. The longest span is where time is being spent.

For database spans, check the SQL:

  • Missing WHERE clause causing a full table scan?
  • Same query running repeatedly? (N+1 problem)
  • Query that needs an index?

Common patterns:

  • Single long span → slow query or external API
  • Many repeated spans → N+1, needs batching
  • Gaps between spans → network latency

Tracking regressions

Compare current metrics to the previous period. If something got worse, check the commit link in recent traces to see what changed. The trace header shows which deployment handled each request.

Request IDs

Every response includes a request ID. Use it to:

  • Jump directly to a trace
  • Correlate client errors with server logs
  • Share specific traces with your team
const response = await client.api.queries.getOrder({ id: "order-123" });
// response.requestId links to this trace in Monitoring