# Logs

## Introduction

Each pool's **Logs** tab shows access-log entries for proxied requests and
[lock](/docs/api/locks) **acquire** attempts (renew/release heartbeats are not
logged): status, timing, queue wait, and outcome. Retention depends on your
[billing](/docs/billing) plan.

## Database pool queries

A [database pool](/docs/pools/database) 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`:

```bash
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](/docs/pools/concurrency#response-cache)

## Next steps

- [Admission errors](/docs/knowledge-base/admission-errors)
- [Pools](/docs/pools)