Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Rate Limiting Settings Block for React

A rate limit you can try: a framed strip replays one client's 24 requests over 10 seconds against the chosen algorithm, limit, window and burst, marking each request allowed or rejected and counting both.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Show what a limit does before it ships, with this rate limiting panel for React with Base UI. Inside a hairline frame with a plus mark on each corner, a framed strip replays the same 24 requests from one client over 10 seconds: each request is an upright tick, solid on the top lane when it is allowed and hollow on the lower lane when it is rejected, with the verdict over it ("16 allowed, 8 rejected") and the first rejection named. Beside it, a Native Select chooses the algorithm (a fixed window, a sliding window or a token bucket), a Number Input sets the limit, a second Native Select the window and a Slider the burst allowance, and a sentence says what that amounts to. Every change replays the same traffic, so the algorithms can be compared on one burst; a fixed window draws its edges, and the burst that straddles one gets through twice. The last band counts unsaved changes in a status line beside a Shine Button to save them and an outline Button to discard them. On a phone the strip comes first. It's built from Native Select, Number Input, Slider, Button, Shine Button and Guides, with hand-built bars and a CSS entrance only. For API gateways, developer platforms and any setting where a number only makes sense next to the traffic it governs.

FAQ

How is each request judged?

By a plain function over the typed requests, run in order. A fixed window allows a request while fewer than the limit have been allowed in its window, and starts the count again at each window edge. A sliding window allows it while fewer than the limit were allowed in the window's length just before it. A token bucket starts full, refills at the limit divided by the window, and spends one token for each request it allows. The burst allowance is the most requests accepted in the same second for the two windows, and the size of the bucket for the token bucket. The result is worked out on every render, so the ticks, the counts and the sentence always agree.

How do I use my own traffic?

Edit REQUESTS, a list of millisecond offsets from the first request, and AXIS_MS, the length of the strip. Keep the ticks at least 200 ms apart so the hollow marks don't overlap at 320 px. SAVED is the setting the account has stored when the page opens, and ALGORITHMS and WINDOWS fill the two menus.

Is the strip accessible?

The ticks are decoration: the strip is one image named with the whole result (the algorithm, the counts and the first rejection), and the same facts are written next to it as text, with the counts in large figures. A rejected request differs from an allowed one by lane and by shape, a hollow bar under the line, so nothing relies on colour. The time axis is drawn left to right in every language, because time on it runs one way.

What stays local, and how do I wire it for real?

All of it. Nothing is limited, counted or sent: Save keeps the setting in this page and says so, and the requests are typed. To make it real, send the saved algorithm, limit, window and burst to your gateway, and feed the strip your own recent requests for a client instead of the typed ones. Run the same decision on the gateway, so what the strip shows is what clients get.

What do Save and Discard do?

The block keeps two copies of the setting, the saved one and the one being edited, and counts how many of the four controls differ ("2 changes not saved yet."). Save makes the edited copy the saved one; Discard puts the saved copy back and redraws the limit field. Both stay in place and focusable while nothing changed, marked aria-disabled, and say so when pressed.

How does it look on a phone?

The strip and its verdict come first, so the effect of a change is on screen above the controls that make it, and the controls stack under it at full width. The sentence under the controls reserves its room, so a longer one never moves the foot, which stays pinned to the bottom of the screen while you scroll.

  • Pro

    A matrix of API limits with the plans across and a number field in every cell, a daily capacity worked out under each plan and a guard that stops a higher plan from allowing less than the plan before it.

  • Pro

    Usage Limits Settings

    Product controls

    A row for each resource with a usage bar, a limit field, a policy for what happens at the limit (default, block, throttle or bill extra) and a sentence that restates the outcome, plus a default every row can follow.

  • Pro

    Cache Policy Settings

    Domains and delivery

    An ordered table of cache rules where first match wins: each path pattern has a freshness bar, how long a copy stays fresh and how long a stale one may be served, a count of the cached paths it really claims, and a purge that counts what it would clear.

  • Pro

    API Key Builder Settings

    API and webhooks

    An API key settings panel with a table of keys, a builder that sets None, Read or Write for each resource, and a try-a-request check that answers Allowed or Denied with the reason before anything is saved.

  • Pro

    A CORS settings panel that checks its own origin list for four unsafe patterns, each with a Fix button that rewrites the list, plus origin rows with an environment tag, a validating add form and a policy band for credentials and preflight cache.

  • Pro

    Developer Tools Settings

    API and webhooks

    Four SDK switches and an environment choice beside a request panel they steer: capture lists six requests, choosing one opens its JSON, and debug, verbose errors and timing each add their own part to what it shows.