Skip to content
Log events

Log events

Event ids are stable across releases. An id is never reused for a different event, so it is safe to alert on one.

IdLevelEvent
1000DebugRequest signed
1001WarningSigning produced no HMAC
1002TraceSigning content computed
1003WarningOutgoing request not sent
1100DebugRequest verified
1101WarningScheme headers missing
1102WarningRequest outside the max-age window
1103WarningNonce replayed
1104WarningSignature mismatch
1105TraceSignature mismatch detail
1200DebugPolicy not found
1201WarningNonce cache not registered
1202DebugScheme not declared by the policy
1210InformationWatching configuration for policy changes
1211InformationPolicies reloaded
1212WarningPolicy reload failed, previous set retained
1300DebugNo HMAC header; authentication skipped
1301WarningOnValidateKeys rejected the credentials
1302DebugAuthentication succeeded
1303WarningAuthentication failed
1310DebugRequested policy not registered

Ranges

RangeEmitted by
1000–1099Signing
1100–1199Verification
1200–1299Factory resolution and policy reloading
1300–1399The authentication handler

Reading a rejection

Each failure mode has its own id, so the id alone says what went wrong:

SeeingMeans
1102Clocks disagree by more than the replay window, or the request really is old
1103The same nonce twice — a genuine replay, or a client reusing one
1104The two sides built different signing content
1101A scheme header was missing from the request
1310 / 1200The request named a policy this host does not have
1202The request named a scheme that policy does not declare — usually a typo
1300Not an HMAC request at all — no header, so authentication was skipped

For 1104, turn on Trace and compare event 1002 on the signer against 1105 on the verifier. See diagnosing a mismatch.

Caller-controlled rejections — 1300, 1310, 1200, 1202 — are Debug, not Warning. An unauthenticated caller can produce them at will, and an edge deployment must not be drivable to unbounded Warning volume by traffic anyone can send.

Private keys

No message at any level carries a private key. A test asserts this over the full sign/verify path with every level enabled.

Signing content (1002, 1105) is not secret — it travels with the request — but it does contain the public key, the nonce and any scheme header values, which may identify a user. That is why it is Trace and off by default.