Skip to content
shadcn.io

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.

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

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.

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.

What moves, and what happens with reduced motion?

The header, the summary and the rail fade up once on load, with CSS transitions. With reduced motion they are off and the block simply appears. The block has no state.

  • Pro

    Incident Severity Changelog

    Incidents and uptime

    An 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 uptime

    A 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 timelines

    A 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 uptime

    A 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 uptime

    A 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 tabs

    A 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.