Skip to main content

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.

​
Why this tool exists

HTTP status codes don’t just sit there quietly. They cause real, visible reactions. A 200 might resolve without a trace. A 401 may trigger an auth prompt. A 403 can lock parts of an interface. A 500 might surface an error page, start retries, or light up monitoring. Custom Status exists to make those reactions observable — without guessing and without faking responses inside application code.

​
What you’re actually testing

When you use Custom Status, you are not testing server logic, business rules, or application flows. You are testing how a real HTTP response is handled once it leaves the network layer. That includes how:
  • Browsers react to navigation or fetch failures
  • Frontend frameworks propagate non‑success responses
  • SDKs retry, stop, or escalate
  • Tools like curl, HTTP clients, or inspectors report outcomes
  • Monitoring systems classify and surface failures

​
Real responses, real behavior

It’s easy to fake an error in code. It’s much harder to replicate what actually happens when the network responds. Custom Status gives you a clean, controlled way to trigger a specific HTTP response and then step back. No payload to parse. No message to interpret. Just the status — and whatever your client decides to do next.

​
When this is useful

Use Custom Status when you want answers to questions like:
  • Does my client retry on 502?
  • Does this SDK throw or resolve on 404?
  • What UI state appears on 401 vs 403?
  • How does this environment treat non‑success responses?
If the question starts with: “What happens if the server responds with…?” This tool is designed for exactly that moment.