Status
Live state of this deployment, read at the moment you loaded
the page. Nothing here is cached. This page is for people; /health is the
liveness probe for machines, and returns the same build identity as JSON.
Availability
No availability history yet. Measurement starts when this build has been running long enough to record it; until then this page reports only the live state above, and the honest answer to "what is your uptime record" is that there is not one to show.
Build
| Overall | Operational |
| Version | 1.0.0 |
| Commit | e7ce072 |
| Build time | 2026-10-14T01:33:29.209Z |
| Running from | source |
| Node | v26.0.0 |
| This build running for | 13d 11h 53m |
| Checked at | 2026-10-27T13:27:10.979Z |
This deploy runs from source rather than a compiled artifact, so the build time is the time the process started. The commit is read from the checkout at boot.
Dependencies
| Dependency | Status | What it does |
|---|---|---|
| Database | Operational | Stores API keys, screening events, and policy configuration. |
| Cache and rate limiting | Operational | Backs rate limits and short-lived counters. |
| Semantic analysis layer | Operational | No screening calls have used the semantic layer in the last hour. |
A dependency marked down does not necessarily take the API down. Screening itself runs in-process: pattern matching keeps working when the database or cache is unreachable, and every screening response reports which analysis layers actually ran.
Machine-readable
GET /statuswithAccept: application/json— this page as JSONGET /health— liveness probe, always JSONGET /version— version and build identity
Something broken that this page says is fine? Tell us at [email protected] for security issues, or support for everything else.