shadcn.io is not affiliated with official shadcn/ui
Incident Timeline Changelog Block for React
One incident as a split: a summary at the start and its four updates on a hairline at the end, each with a stage badge, a time in UTC, an elapsed chip counted from the first update and one sentence.
Installation
Overview
An incident timeline for React with Base UI, written for Lanternfall, a fictional hosted database. A split with a divider that runs from the top rule to the block's end: at the start the title, one sentence and a summary of the incident (what it was, when it began, how long it lasted, the components it touched, and a ghost link to follow it); at the end its four updates, Investigating, Identified, Monitoring and Resolved, hang off a hairline with their dots on one line. The resolved dot is filled and the others are rings. Each update shows its stage as an outline badge with an icon and a word, its time in UTC, an elapsed chip counted from the first update ("+23 min", "+1 h 27 min") and one sentence. The times are typed in minutes and the chips and the total duration are computed from them, so they always agree. On a phone the summary comes first and the updates sit under it, on the same hairline. It's built from Guides, Badge and Button, with CSS transitions for the entrance and your theme's tokens for every colour. For status pages, post-incident notes and changelogs that report an outage as it unfolded. The incident is example data.
FAQ
How do I change the incident?
Edit UPDATES and DAY at the top of the file. An update is an at (minutes after midnight UTC on DAY), a message and a stage; the first update is the incident's start, and the last should be Resolved. The time on screen ("08:14 UTC") is spelled out from the minutes, the elapsed chip is counted from the first update, and the total duration in the title and the summary is the last update minus the first, so nothing is typed twice. The date is a fixed ISO day, never computed from today.
How are the stages told apart without colour?
Each stage is an outline badge with an icon and the word, so it reads in greyscale and to a screen reader, which hears the word and skips the icon. On the rail the resolved update has a filled dot and the others a ring, so the end of the incident is visible without reading. The four stages are constants at the top of the file, each an icon, an id and a label.
Where does Follow this incident go?
It is a ghost button that is a link (href="#"): point it at your subscription page or the incident's own page. The block has no primary button, because following an incident is not the page's main action.
The button renders the link it's given with render, with nativeButton={false}.
How is this different from the release timeline?
The release timeline is one column of releases on a rail with a date column. This one is about a single incident and is split in two: the facts at the start, the updates at the end, with a divider from the top rule to the foot of the block, a stage badge for each update and an elapsed chip rather than a version and a date.
How does it fit on a phone and in a right-to-left layout?
Below lg the two halves stack: the summary first, then a rule, then the updates on their hairline at the start edge. Nothing scrolls sideways at 320 pixels; the stage, time and chip wrap onto a second line if they must. In a right-to-left layout the hairline and dots move to the right edge, the arrow turns, and times and durations stay in reading order.
Related
- Pro
Incident Severity Changelog
Incidents and uptimeAn incident log grouped under P0 to P4 headings, with a toggle group that filters it, a band of five median-time-to-resolve cells and rows of id, title, users affected and state, each severity a shape and a word.
- Pro
Post-Mortem Changelog
Incidents and uptimeA blameless post-mortem as one framed report: three impact cells, a five-whys accordion from the symptom to the root cause, and an action-items table with owners, due days and states beside a progress bar.
- Pro
Release Timeline Changelog
Lists and timelinesA release timeline for an API client: a compact header with a Subscribe link, then the latest four releases on a hairline rail with dots, each with its version, date, type tags, a linked title and its notes, and View all releases at the foot.
- Pro
Split Status Page
Incidents and uptimeA split status page for a hosted status service: the 90-day uptime and four components with their state at the start, the three most recent releases at the end, and a divider between them.
- 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
Expandable Timeline Banner
Disclosures and tabsA parcel notice for a tracking product as a disclosure: a header that names the current stage and its step, and a vertical four-step timeline when opened.