Requests, routes and traces

Open Activity and choose a page in the Requests group. Use the time buttons (15 minutes up to 14 days) to widen or narrow the window.

Routes

Routes lists every route your API serves with how many calls it got, how many failed, and how long it took. Sort by errors or by slowness to find what needs attention. Open a route to see:

Section	What it shows
Traffic and failures	Calls over time and how many succeeded
Slowest requests	The slowest calls, each one a click away from its trace
What went wrong	The errors it returned, grouped
Where the time goes	Time spent in the database, in flows, in other work

Requests

Requests is the full list. Search by path or by an exact request id, and filter by status (404, or a class like 5xx). Every request has a request id. It appears on the response (x-request-id) and on the events, flow runs and webhook deliveries that call caused, so you can follow one action through everything it set off.

A request trace

Open any request to see it end to end:

Who called (which key or user) and from where.
The access-rule decision, including why a call was refused. See Debugging rules.
DB queries it ran, how many and how long each took.
Events and jobs it started.
Flow runs it triggered.
Logs your flows wrote during it.
A timing waterfall of the steps.

Find why a call failed

In your app, catch the error and read its requestId.
Open Activity → Requests and paste it into the search.
Open the trace and read the decision and the steps.

Errors

Errors groups failures by what went wrong, so one problem shows up once with a count instead of a thousand times. Open a group to see the requests behind it.

Bandwidth

Bandwidth shows the bytes your API received and sent over the window, and the endpoints, callers and requests that moved the most, including the largest responses. Headers are not counted, only what the request and response carried. Use it to find a route that sends far more than it should.

What a request records

Field	Meaning
`request_id`	The id, also in the `x-request-id` response header
`method`, `path`, `route`	What was called, and the route pattern it matched (`/rest/v1/orders/{id}`)
`status`	The status answered
`duration_ms`	How long it took
`started_at`	When it started
`role`, `user`	The key’s role (publishable, secret) and the signed-in person, if any
`ip`, `user_agent`	Where it came from
`error`	The error, for a failed request
`bytes_in`, `bytes_out`	What the request and response carried

From code

# failing requests in the last hour
curl "$PAWABASE_URL/platform/v1/envs/production/requests?status=5xx&minutes=60" -H "apikey: $PAWABASE_SECRET_KEY"
# one request with its trace
curl "$PAWABASE_URL/platform/v1/envs/production/requests/$REQUEST_ID" -H "apikey: $PAWABASE_SECRET_KEY"

const m = manage(pawabase);
const failing = await m.observability.requests({ status: "5xx", search: "/rest/v1/orders" });

Endpoint	Query
`GET …/requests`	`request_id`, `method`, `status` (a code like `404` or a class like `5xx`), `search` (part of the path), `minutes` (up to 30 days)
`GET …/requests/{request_id}`	One request with its trace
`GET …/observability/routes`	Per-route traffic, failures and latency
`GET …/observability/errors`	Failures grouped by what went wrong
`GET …/observability/bandwidth`	Bytes in and out, and the biggest endpoints, callers and requests (`minutes`)

Good practice

Open Errors after every release.
Put the request id in your own error reports and support messages.
Keep personal data and secrets out of what your flows log.

Environments

Activity

Secrets and backups

Pawabase Cloud

Requests, routes and traces

Routes

Requests

A request trace

Find why a call failed

Errors

Bandwidth

What a request records

From code

Good practice

​Routes

​Requests

​A request trace

​Find why a call failed

​Errors

​Bandwidth

​What a request records

​From code

​Good practice

Routes

Requests

A request trace

Find why a call failed

Errors

Bandwidth

What a request records

From code

Good practice