Observability

You cannot trust what you cannot see. A platform that hides how it behaves asks you to take its word for everything; a platform that records what it does lets you verify. CTXR keeps three separate records of its own behaviour, exposes a health signal anyone can check, and counts what matters — deliberately kept apart, because each answers a different question for a different audience.

Three separate trails

The instinct to pour everything into one log is the wrong one. Authentication evidence, request debugging, and runtime errors have different audiences and different retention needs, so they live apart.

Trail	Records	For
Audit log	What an actor did to data — who changed what, when	Forensics and compliance
Edge log	HTTP request metadata, never bodies or tokens	Debugging and abuse / DDoS analysis
Runtime log	How the system behaved — errors, warnings, slow operations	Operations

The audit log is the compliance trail: a durable record of which actor created, edited, published, or deleted which node. It is the answer to “who touched this?” and it is kept for as long as compliance requires.

The edge log captures request metadata — method, path, timing, status — but deliberately never the request body or the bearer token. It is for spotting a broken integration or a traffic anomaly, not for reading what was sent.

The runtime log is the system’s own diary: errors and warnings, and slow queries. Notably, an operation that crosses the slowness threshold (over 500 ms) is reported, not aborted — the system tells you it was slow and still completes the work, so a performance signal never turns into an outage.

A health endpoint

A dedicated health-check endpoint reports the status of each subsystem and can be polled anonymously — by an uptime monitor, a load balancer, or you. It is the first thing to check when something seems wrong, and the green light a deployment pipeline waits for before sending traffic to a new release.

Metrics as plain counters

Beyond logs, the platform keeps metrics as simple counters: how often something happened, how long it took. These are written out periodically in an open, readable form rather than shipped to a proprietary monitoring vendor — so there is no lock-in, and the numbers are yours to read with ordinary tools.

Why keep them separate

Folding these into one stream would be convenient and wrong. Audit evidence must outlive a debugging log; request metadata must never mix with the bodies and tokens it deliberately omits; an operator chasing an error does not want to wade through compliance records. Different retention, different audience, different purpose — kept apart on purpose.