Status & Delay
Between the response variant tabs and the three sub-tabs of the Response Panel sits a thin two-column row with the HTTP status code on the left and the artificial delay on the right. Both fields apply to the endpoint as a whole — regardless of which variant ends up being returned, the status and delay come from this row.
Status Code
The status field is a searchable dropdown. Clicking it opens a small panel with a search input at the top and a list of status codes underneath. The list works in two modes:
- •Empty search: shows the most common status codes (200, 201, 204, 301, 400, 401, 403, 404, 500, and a few more) so you can pick the right one with a single click.
- •Text search: typing in the search input filters the full HTTP status list by code or name. Searching for teap finds 418 I'm a teapot; searching for 429 finds 429 Too Many Requests.
- •Custom code: if you type a number between 100 and 599 that Tigrister does not have a name for, the list offers a single row labelled "Custom status". Selecting it — or simply pressing Enter — sets the endpoint to that code.
The button face always shows the currently-selected code together with its name, for example 200 OK or 503 Service Unavailable.
Delay
The delay field on the right of the row is the number of milliseconds the mock waits before sending its response. It takes only digits — non-numeric characters are stripped as you type — and an empty value is treated as zero.
- •0 (or empty): the response is sent immediately. This is the default for new endpoints.
- •A small number: useful for simulating a slightly slow server (for example 250) so your UI's loading states get a chance to appear.
- •A large number: useful for simulating a congested or broken backend, testing timeouts, or verifying that a progress spinner really does appear when requests take a long time.
The delay is applied the same way for every variant the endpoint might return — rules decide which variant is sent, while this field decides how long the server waits before sending it.