Monitoring

To see how your APIs are doing, choose Monitoring → Dashboard in the Pods sidebar. Narrow it with the API and Stage filters, and pick a Time range: Last hour, Last 24 hours (the default), Last 7 days or Last 30 days. Refresh loads the latest numbers.

• Requests, 4XX errors and 5XX errors: totals for the range, with each error type as a share of requests.
• Latency p90: the time nine in ten requests finish within, with p99 beneath.
• Traffic: requests and errors per 5 minutes, hour or day, depending on the range.
• Latency: p50, p90 and p99 over the same intervals.
• Latency and cache: for the most recent interval, the three latency percentiles, Integration p90 (time spent waiting on the backend) and the Cache hit ratio for REST stages that cache.

Test invocations from the API editor aren't counted. Each API also has a Monitoring section in the API editor that shows the same dashboard for that API alone.

Choose Monitoring → Logs to see access log lines from live traffic, newest first. Lines appear once a stage with access logging turned on serves requests, as the Deployments and stages guide describes. Everyone on the project can open Logs.

• Status class: 2xx success, 4xx client errors or 5xx server errors.
• Stage: the stages seen in recent lines.
• Search by: Request ID, Route or Source IP. Search matches the whole value exactly.

Each line shows the request, its status, stage, source IP and time. The screen loads the latest 50 lines; choose Live tail to refresh them every 2 seconds, and again to stop. Click a line, or choose Open in its ⋯ menu, to see the request's details. Copy request ID copies its ID.

Opening a line in Monitoring → Logs shows everything recorded for that request. All Logs goes back.

• Access log: the time, status, stage, route, source IP and request ID.
• Execution log: each step the gateway took. It's recorded only when the stage's execution logging level is Errors only or Info.
• Trace: the spans of the request's trace, in start order, when the stage has tracing on and the request was sampled.

Request and response bodies appear in the execution log only when the stage has data trace on, and only Owners, Admins and Managers can see them. For Members they're hidden.

An alarm watches one gateway metric and notifies you when it crosses a threshold. Choose Monitoring → Alarms, then New Alarm. Only Owners and Admins can manage alarms.

• Name: required, up to 128 characters.
• Metric: grouped as REST (such as Count, 4XXError, 5XXError, Latency), HTTP (4xx, 5xx, DataProcessed), WebSocket (such as ConnectCount, MessageCount) and Gateway (such as ThrottleCount, QuotaRejectCount, AuthorizerLatency).
• Statistic: Sum (the default), Average, Minimum, Maximum, SampleCount, p50, p90, p95 or p99.
• Comparison and Threshold: greater than, greater than or equal, less than, or less than or equal to a number. They start at greater than 10.
• Period (seconds): a multiple of 60, 300 to start with.
• Evaluation periods (N) and Datapoints to alarm (M): the alarm breaches when M of the last N periods breach, 2 of 3 to start with. N is 1 to 60.
• Treat missing data as: Missing (keep state), the default; Not breaching; Breaching; or Ignore.

Choose Create Alarm. The alarm's page opens, where you pick who gets notified.

Every alarm is in one of three states: OK (within the threshold), In alarm (breaching) or Insufficient data (not enough datapoints to decide). The figures on the Alarms screen count Total alarms and each state.

Filter the list by State, or search by name or metric. Each row shows the alarm's state, the reason for it and when it last changed. Its ⋯ menu has Edit (or Open), View history, Enable or Disable, and Delete.

On the alarm's page, Condition holds the settings from when you created it, plus a description, and the switch at the top turns the alarm on or off. Choose Save Changes after editing. History lists each state change with its reason, newest first. Deleting an alarm asks you to confirm, stops its evaluation and removes its history; it can't be undone.

Alarms notify notification channels, which every alarm in the project shares. Open an alarm and choose Notifications.

1. Under Notification channels, choose New Channel.
2. Type a Name, pick the Type, Webhook or Slack webhook, and type its URL. It must be an https address.
3. Choose Create Channel.
4. Under Notify on state change, select the channels for each change: Enters alarm, Returns to OK and Insufficient data.
5. Choose Save Changes.

Each state change notifies its channels once. A webhook receives a JSON POST with the alarm and the reason, and a Slack webhook receives a short message. To remove a channel, choose Delete in its ⋯ menu and confirm. Alarms that notified it stop sending there.

Log exports send access log lines to your own systems. Each destination is a sink. Choose Monitoring → Log Exports, then New Sink. Only Owners and Admins can manage sinks.

• HTTPS: signed batches of NDJSON posted to your URL. Signing secret ref names the secret used to sign them, in the x-pods-signature header.
• S3: gzipped NDJSON objects in an S3-compatible Bucket, under an optional Prefix, using the secret in Credentials ref.
• OTLP logs: log records sent to an OpenTelemetry collector's Endpoint.

Secret refs take the form secret: followed by a secret's ID, and optionally @ and a version. Choose Create Sink. A sink receives nothing until a stage sends to it: add the sink's ID to the stage's access log Destinations.

The Log Exports screen counts Total sinks and how many are Active, Failing (the last delivery failed) or Disabled. Filter by Type and Status, or search by name, destination or ID.

Each sink's ⋯ menu has Send test batch for HTTPS sinks, Copy sink ID, Enable or Disable, and Delete. A sink's page shows its destination, a Deliver logs switch, its Last delivery, its Last error and its Sink ID. A disabled sink sends nothing, and stages keep pointing at it until you turn it back on.

Deleting a sink asks you to confirm. Stages that sent logs to it stop exporting there, and it can't be undone.