How to Access API Gateway Logs (By Platform)

How to Access API Gateway Logs

Where you find API gateway logs depends entirely on which gateway you're running. Managed gateways like AWS API Gateway and Azure API Management push logs into a platform-native logging service (CloudWatch, Application Insights) that you query through a console or CLI. Self-hosted gateways like Kong, Nginx, or Envoy write logs to local files, stdout, or a syslog target you configure yourself.

The short answer: enable access logging (and execution/error logging if your gateway separates the two), point it at a log destination you can actually query, and make sure request IDs or correlation IDs are included so you can trace a single call across services. The rest of this article walks through the specifics for the most common setups.

AWS API Gateway

AWS API Gateway supports two log types, and people often only enable one:

• Access logs — one line per request, with fields you choose (status code, latency, IP, request ID).
• Execution logs — detailed request/response data including integration errors, useful for debugging but noisier and more expensive.

To enable access logs:

1. Go to the stage settings for your API in the console (or use aws apigateway update-stage).
2. Turn on Access Logging and point it at a CloudWatch Logs group ARN.
3. Define a log format — a JSON object is easier to query than the default string format.

{
  "requestId": "$context.requestId",
  "ip": "$context.identity.sourceIp",
  "status": "$context.status",
  "latency": "$context.responseLatency",
  "path": "$context.path",
  "method": "$context.httpMethod"
}

Then read them with the CLI:

aws logs tail /aws/apigateway/my-api --follow

For execution logs, enable CloudWatch Logs under stage settings and set the log level to INFO or ERROR. Remember that execution logs cost more to store and can leak request/response bodies if you're not careful — scrub sensitive fields before enabling INFO level in production.

Kong

Kong doesn't ship logs anywhere by default — you attach a logging plugin per service or globally:

• file-log writes JSON lines to a local file.
• http-log / syslog ship to an external collector.
• tcp-log / udp-log for streaming pipelines.

Example, enabling file logging on a service:

curl -X POST http://localhost:8001/services/my-service/plugins \
  --data "name=file-log" \
  --data "config.path=/var/log/kong/access.log"

Once enabled, tail -f /var/log/kong/access.log gives you structured JSON per request, including latency breakdowns for the gateway, upstream, and total request time — useful for isolating whether slowness is Kong or your backend.

Azure API Management

Azure APIM logs to Application Insights if you've linked it during setup. If you haven't, no logs exist beyond basic Azure Monitor metrics, so this is the first thing to check when someone says "I can't find any logs."

To wire it up:

1. In the APIM instance, go to Application Insights under monitoring.
2. Link (or create) an Application Insights resource.
3. Attach the Diagnostic Settings at the API or product level with sampling rate and log level.

Query logs with Kusto in Log Analytics:

requests
| where cloud_RoleName == "my-apim-instance"
| project timestamp, name, resultCode, duration
| order by timestamp desc

APIM also supports sending diagnostics straight to an Event Hub or Storage Account if you want raw log files instead of the Application Insights UI.

Nginx and generic reverse proxy gateways

If your "API gateway" is Nginx, Envoy, or Traefik acting as the entry point, logs are just access logs, configured like any web server:

log_format api_json escape=json
  '{"time":"$time_iso8601","status":"$status",'
  '"request":"$request","request_time":"$request_time",'
  '"upstream_time":"$upstream_response_time"}';

access_log /var/log/nginx/api_access.log api_json;

The key addition for API gateways specifically is upstream_response_time — it tells you how much of the latency is your backend versus the proxy itself, which is the first thing to check when a request is slow.

What to look for once you have access

Regardless of platform, the fields that actually matter for debugging are:

• Request ID / correlation ID — lets you trace one call across gateway, service, and downstream calls
• Status code and latency — separate gateway-added latency from upstream latency
• Client identity — API key, IP, or auth subject, so you can filter by caller
• Route matched — confirms the gateway sent the request where you expected

If your gateway logs don't include a stable request ID by default, add one — most gateways let you generate or forward one via a header (X-Request-Id) and echo it back in the response so clients can reference it in support requests.

Where a managed API layer changes this

If you're running your own gateway in front of a third-party API, you're maintaining log plumbing (CloudWatch groups, retention policies, dashboards) just to answer "why did this request fail?" That's a reasonable tradeoff at scale, but it's overhead if you're a small team wrapping a single upstream API.

SubToAPI exposes request-level usage metadata (status, tokens, latency) per application key directly in the dashboard, so you're not standing up your own logging pipeline just to see what your app is doing against the API. Every key is scoped and traceable back to a specific application or team member, which covers most of what people build custom gateway logging for in the first place. See the quickstart or the messages API docs for how requests are structured, and pricing for plan details.

Questions

Where are AWS API Gateway logs stored by default? Nowhere — logging is off by default. You have to enable access logging and/or execution logging on the stage and point it at a CloudWatch Logs group before anything is captured.

Can I access API gateway logs without CloudWatch or Application Insights? Yes. Most gateways (Kong, Nginx, Envoy) can write logs to a local file, syslog, or a custom HTTP/TCP endpoint, so you can ship them to whatever log aggregator you already run (Datadog, Loki, ELK).

Why don't I see any logs in Azure APIM? Almost always because Application Insights was never linked to the APIM instance, or diagnostic settings weren't configured at the API/product level — logging isn't automatic on creation.