shadcn.io is not affiliated with official shadcn/ui
API Response Time Changelog Block for React
Paired bars for five endpoints on a shared 0 to 400 ms axis, the previous release pale and this one solid, with the change in rolling percent digits, the optimisation behind it and a p50, p95 or p99 toggle that redraws the bars.
Installation
Overview
An API performance changelog for React with Base UI, written for Hastemark, a fictional API monitor. A start-aligned header carries the title, one sentence and a toggle group (p50, p95, p99) with a polite line that sums up the percentile showing: how many endpoints got faster and by how much on average. A framed figure sits on the page's lines with + marks on its corners: each endpoint is a row with two bars on a shared 0 to 400 ms axis, the previous release's pale and this release's solid, then the two figures in milliseconds, a down arrow and the change in percent (digits that roll), and the optimisation behind it. Choosing a percentile redraws the bars and rolls the percentages. The drawing is hidden from assistive technology and an unseen table in the figure holds all three percentiles. On a phone the percent sits under the bars. It's built from Toggle Group, Sliding Number and Guides, with CSS transitions for the bars and your theme's tokens for every colour. For performance reviews, release notes and status pages. The timings are example data.
FAQ
How do I change the endpoints and timings?
Edit ENDPOINTS at the top of the file. An endpoint is an id, a path, the fix that made it faster and its timings: for each percentile the was and now milliseconds. The bar widths, the percentages and the summary line are all computed from those numbers. CEILING sets the axis's end (400 ms here), so keep every value below it.
Why one shared axis?
Both bars of every endpoint, and every endpoint, are drawn to the same 0 to 400 ms scale, so a longer bar always means a slower answer and endpoints can be compared by eye. The figures are written out beside the bars too, so the picture never carries a number alone.
What does a screen reader get?
The drawn rows are hidden from assistive technology on purpose. In their place the figure holds a table with a caption: one row per endpoint and the previous and current milliseconds for p50, p95 and p99, whatever the toggle shows. The summary line is a polite live region, so each choice announces how many endpoints got faster.
How does the toggle work?
It is a single-choice group with one button always pressed; the arrow keys move between p50, p95 and p99. A choice changes the bars' widths with a CSS transition and rolls each percentage's digits to the new value. With reduced motion the bars and digits change at once.
How does it fit on a phone and in a right-to-left layout?
Below lg each row stacks: the path, then the bars full width, then the percent beside the two figures and the optimisation. The axis and every bar keep their left-to-right direction in a right-to-left layout, since a time scale doesn't mirror, and the figures and percentages stay left to right.
Related
- Pro
API Usage Metrics Changelog
APIs and integrationsSix weeks of requests as stacked columns by API version, the legend and title reading the latest week's shares from the data, a Requests or Share toggle, and a three-cell band of requests, error rate and p95 latency with their changes.
- Pro
Segmented Bar Latency Budget
Metrics and chartsA single bar that slices a 250 ms request budget by hop (edge, auth, database, render), a switch between two releases that re-slices it, and a four-cell band with each hop's milliseconds and its change.
- Pro
Error Rate Comparison Changelog
Incidents and uptimeFour error classes as rows, each a 14-day line split by a release marker with the average after it and the change as an arrow and a sign, plus a switch for one shared scale.
- Pro
API Changes Changelog
APIs and integrationsA band of ruled rows listing changed API endpoints, each with its method, path, one line on what changed, a kind (Added, Changed, Removed) and its version, filtered by HTTP method with a toggle group that sums up what is showing.
- Pro
Tabbed Window Uptime History
Incidents and uptimeA tabbed window of ninety-day uptime for an uptime monitor: one tab per service, a large uptime figure that rolls to the new service, a strip of ninety daily bars and a three-row table of incidents.
- Pro
Plan Cells Rate Limit Dashboard Changelog
APIs and integrationsThree plan cells showing usage against a new hourly limit: a rolling count of requests, a progress bar with a tick at 80%, the remaining requests, the share used, the new limit with the old one struck through and the pace, with a toggle between the current hour and the peak hour.