Documentation Index
Fetch the complete documentation index at: https://docs.utnor.com/llms.txt
Use this file to discover all available pages before exploring further.
How Custom Status works
Custom Status works by doing one thing, and doing it consistently.
You ask for a status code. The tool responds with that exact status code. Then it’s done.
There’s no state carried forward, no memory of previous requests, and no hidden steps in between. Every request stands on its own.
Stateless by design
Custom Status is fully stateless.
Nothing about the request is stored after the response is sent. This keeps behavior predictable and avoids side effects that could change results between runs. You get the same response today, tomorrow, and next week — as long as the input is the same.
This also makes the tool easy to reason about when you’re testing or observing behavior.
Deterministic behavior
Custom Status is deterministic.
The same request will always produce the same response.
There is no state, memory, or variation between calls.
This makes the tool reliable for testing, debugging, and observing behavior across different clients and environments.
Simple code, simple hosting
The tool is implemented in TypeScript and designed to be minimal on purpose.
There’s no heavy setup or environment-specific dependency. If you want to self-host it, you can run it on any stateless server without changing how it behaves. Hosted or self-hosted, the response logic stays identical.
If you’re curious about the exact implementation, the source code shows the full flow clearly.
Open and transparent
There’s no magic happening behind the scenes.
The full implementation of Custom Status is open and available on GitHub. If you’re curious about how the tool behaves internally, you can read the code directly and follow the request-to-response flow end to end.
The logic that defines the tool’s behavior is intentionally small and easy to follow. What you see in the code reflects how status resolution and response handling work, without unnecessary abstraction or indirection.
The hosted version follows the same behavior and response rules. Additional operational layers exist only to ensure the tool runs safely and reliably at scale, without changing what the client receives.
This openness makes the tool easy to trust, easy to audit, and easy to run on your own if you ever want to self-host it.