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:
| Metric | What it tells you |
|---|---|
| Requests | Total API calls |
| Error rate | Percentage that failed |
| Avg duration | Typical response time |
| P99 duration | Slowest 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