Logs
Introduction
Each pool's Logs tab shows access-log entries for proxied requests and lock acquire attempts (renew/release heartbeats are not logged): status, timing, queue wait, and outcome. Retention depends on your billing plan.
Database pool queries
A database pool logs one entry per query, written when
the query finishes — including one that outlived waitMs and completed as a
job. Alongside the usual timing and outcome, a query entry carries the statement
(truncated), how many rows came back, whether it was capped, and the
key that ran it.
That last column is what makes "who ran what against production" answerable — a shared connection string cannot tell you, because the database only ever sees one user.
A statement the database refused — a write attempted under a read-only role, or a table the role was never granted — is recorded as its own outcome rather than as a generic failure, with the statement text kept. A rejection there is an attempt to escape read-only mode, and the statement is the only useful evidence of what was tried.
Tags
Callers can attach a short searchable tag with X-Nthpool-Tags:
curl -sS "https://your-pool.nthpool.cloud/v1/orders" \
-H "X-Nthpool-Key: $POOL_KEY" \
-H "X-Nthpool-Tags: celigo-order-sync"Tags are sanitized and capped at 64 characters. They are stored only in access logs. They do not affect admission.
What to look for
- Auth failures (
401/403) before a slot is taken - Admission rejects (
429,504) vs upstream status codes - Queue wait (
queued-ms) when the pool is saturated - Cache hits (still metered as requests) when using response cache