Source Code

<div class="demo">
  <div class="tile">
    <div class="tile-head">
      <div class="rel-name">
        <svg width="15" height="15" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2.2" stroke-linecap="round" stroke-linejoin="round"><path d="M12 2L2 7l10 5 10-5-10-5z"/><path d="M2 17l10 5 10-5M2 12l10 5 10-5"/></svg>
        <span>checkout-service <b>v2.14.0</b></span>
      </div>
      <span class="badge rolling" id="statusBadge">Rolling out</span>
    </div>

    <div class="stages" id="stages"></div>

    <div class="metrics">
      <div class="metric">
        <span class="m-label">Error rate</span>
        <span class="m-val ok" id="errRate">0.04%</span>
      </div>
      <div class="metric">
        <span class="m-label">p95 latency</span>
        <span class="m-val ok" id="latency">118ms</span>
      </div>
      <div class="metric">
        <span class="m-label">Traffic on canary</span>
        <span class="m-val" id="trafficPct">5%</span>
      </div>
    </div>

    <div class="tile-actions">
      <button class="btn rollback" id="rollbackBtn">Roll back</button>
      <button class="btn promote" id="promoteBtn">Promote now</button>
    </div>
  </div>
</div>

Canary Rollout Progress Tile — Free HTML CSS JS Snippet

Canary Rollout Progress Tile · Dashboards · Plain HTML, CSS & JS · Live preview

What's included

Features

Discrete staged progress track (not a continuous bar) with checkmarked done stages and a pulsing active stage
Guardrail metrics (error rate, p95 latency) colored ok/warn/bad independent of overall rollout status
Explicit Promote and Rollback actions that both disable further automatic advancement
Rollback preserves the stage the rollout was at when halted, rather than resetting progress
Promote jumps directly to the final stage rather than requiring every intermediate stage to be clicked
Traffic-on-canary percentage always reflects the currently active stage's configured value
Auto-advance timer structured as a drop-in replacement point for a real deployment orchestrator poll
Compact single-tile layout suited to a grid of other release/ops dashboard widgets

About this UI Snippet

Canary Rollout Progress Tile — Staged Traffic, Guardrail Metrics & Promote/Rollback

Screenshot of the Canary Rollout Progress Tile snippet rendered live

A canary rollout ships a new version to a small slice of traffic first, watches health metrics, then gradually increases that slice — the opposite of an all-at-once deploy. This tile visualizes exactly that: a staged progress track (5% → 25% → 50% → 100% of traffic), live guardrail metrics (error rate and p95 latency) that would justify continuing or aborting, and explicit promote/rollback controls, all wired to one small state machine.

The stage track models discrete steps, not a continuous bar

Unlike a generic progress bar, STAGES is an explicit array of traffic percentages, and stageIndex is an integer pointing at the current one. renderStages() marks every stage before stageIndex as .done (filled, checkmark), the current one as .active (pulsing ring animation via a box-shadow keyframe), and later ones as neutral. This matters because a real canary rollout doesn't move continuously — it holds at each traffic percentage for an observation window before deciding to advance, so a discrete stepped track communicates the actual deployment model more honestly than a smooth 0–100% bar would.

Guardrail metrics colored independently of rollout status

errEl and latEl get their own ok/warn/bad class based on fixed thresholds (refreshMetrics()), completely independent of whether the rollout badge currently says "Rolling out" or "Promoted." This separation is intentional — in a real system, these are exactly the numbers an automated canary analysis tool (or an on-call engineer) would watch to decide *whether* to let the rollout advance, so they need to be legible as their own signal rather than folded into a single combined status.

Promote and rollback as explicit terminal actions

Clicking "Promote now" jumps stageIndex straight to the final stage and calls setStatus('promoted'); clicking "Roll back" calls setStatus('rolledback') without touching stageIndex at all — deliberately, since a rollback's whole point is to stop admitting more traffic to the new version, not to pretend the rollout continued. Both actions disable further stage auto-advancement and both buttons, because a canary rollout has exactly one live decision point at a time; once promoted or rolled back, the only next action is starting an entirely new rollout.

The auto-advance timer as a stand-in for a bake-time scheduler

setInterval(advance, 4000) simulates the automatic stage-advancement a real canary pipeline (Argo Rollouts, Flagger, or a custom deployment controller) would run on a bake-time schedule, typically minutes to hours per stage rather than seconds. Swap the interval callback for a webhook or polling call to your actual deployment orchestrator's status API, and the same renderStages()/refreshMetrics() functions apply the real state.

Build with AI

Build, Understand, Optimize, and Extend It With AI

Paste this snippet's HTML, CSS, and JS into an AI coding assistant like Claude and ask it to explain exactly why rollback leaves stageIndex unchanged while promote jumps it straight to the last stage, and what that distinction is meant to communicate about how a real canary rollout's state should be represented. The same assistant can help optimize it — for instance asking whether the guardrail metric thresholds should be configurable per-service rather than hardcoded constants, or whether an automated rollback should trigger itself once error rate crosses the bad threshold rather than requiring a manual click. It's also useful for extending the tile: ask it to add an automatic-rollback-on-breach behavior, a bake-time countdown per stage, or a small sparkline of the error-rate trend across the whole rollout. Treat the code less like a finished artifact and more like a starting point for a conversation.

Prompt to recreate it

Copy this into your AI assistant of choice to build the effect from scratch, or as a jumping-off point for your own variant:

text
Build a "canary rollout progress" dashboard tile in HTML, CSS, and vanilla JavaScript — no charting library.

Requirements:
- Model the rollout as a fixed array of discrete traffic-percentage stages (for example 5%, 25%, 50%, 100%) and a single current-stage index — render each stage as a dot in a horizontal track, visually distinguishing stages already passed (filled, with a checkmark), the currently active stage (a distinct pulsing highlight), and stages not yet reached.
- Show at least two live guardrail metrics (for example error rate and p95 latency) that update on every stage advance, each independently colored across at least three states (healthy, warning, critical) based on numeric thresholds — this coloring must be completely independent of the rollout's own promoted/rolled-back/rolling status.
- Provide a "Promote now" button that jumps the current-stage index directly to the final stage and marks the rollout as fully promoted, and a separate "Roll back" button that halts the rollout immediately at whatever stage it is currently on (without resetting or changing the stage index) and marks it as rolled back.
- Once either promote or rollback has been triggered, disable both action buttons and stop any further automatic stage advancement.
- Simulate automatic progression through the stages with a repeating timer (representing a bake-time wait between stages in a real system) that only advances while the rollout is still in its default "rolling out" state, refreshing the guardrail metrics with newly randomized-but-plausible values at each stage change.

Want to tighten it up first? Run this prompt through the AI Prompt Studio to score it across 8 quality dimensions, catch anti-patterns, and tune the wording for Claude, ChatGPT, or Gemini before you paste it in.

Step by step

How to Use

  1. 1
    Watch it auto-advanceThe tile auto-advances through traffic stages every 4 seconds in the demo — refreshing error rate and latency metrics at each stage.
  2. 2
    Click Roll backImmediately halts the rollout at its current stage and switches the badge to a rolled-back state, disabling further actions.
  3. 3
    Click Promote nowJumps straight to the final 100% stage and marks the release as fully promoted.
  4. 4
    Edit the STAGES arrayChange the traffic percentages and number of stages to match your own canary pipeline's configuration.
  5. 5
    Adjust guardrail thresholdsEdit the error-rate and latency cutoffs inside refreshMetrics() to match your service's actual SLOs.
  6. 6
    Connect a real deployment APIReplace the setInterval simulation with polling or a webhook from your deployment orchestrator (Argo Rollouts, Flagger, or similar) that updates stageIndex and the metric values.

Real-world uses

Common Use Cases

OPS
Internal deploy/release dashboards
Give an on-call or release engineer a live view of an in-flight canary rollout without leaving the ops dashboard for the deployment tool's own UI.
CI/CD pipeline status pages
Surface canary rollout stage and guardrail health as one tile among several pipeline-stage widgets on a build/deploy status page.
ALERT
On-call incident response tooling
Let an on-call engineer roll back a suspicious release directly from the same dashboard used to notice a metric regression.
Progressive delivery platform UIs
Adapt as the core widget for a progressive-delivery tool (in the spirit of Argo Rollouts or Flagger) showing live canary analysis status.
Related: Deployment Pipeline Stage Tracker
See the Deployment Pipeline Stage Tracker for a related dashboards pattern worth pairing with this one.

Got questions?

Frequently Asked Questions

The stage track is a fixed set of discrete traffic-percentage steps (STAGES), not a continuously animating fill. Each stage renders as its own dot marked done, active, or pending, because a real canary rollout holds at each percentage for an observation window rather than moving smoothly — a stepped track communicates that model more accurately.

errEl and latEl are colored ok/warn/bad from fixed numeric thresholds inside refreshMetrics(), entirely independent of the rolling/promoted/rolledback badge state. This mirrors how a real canary analysis works: the metrics are the signal used to decide whether to let the rollout continue, so they need to be readable on their own rather than folded into the overall status.

Nothing — rollback intentionally leaves stageIndex untouched, since the point of a rollback is to stop the rollout at whatever traffic percentage it had reached, not to pretend progress continued. Only the status and badge change, and both buttons become disabled.

No — it sets stageIndex directly to the last entry in STAGES and calls setStatus("promoted") immediately, modeling a manual "just ship it to 100%" override rather than requiring the auto-advance timer to step through every stage first.

Replace the setInterval(advance, 4000) simulation with a polling call (or webhook handler) against your deployment orchestrator's status API, updating stageIndex and calling refreshMetrics() with real error-rate and latency values whenever the orchestrator reports a stage change.

Yes — STAGES is a plain array of traffic percentages; add, remove, or change entries and the stage track, traffic-on-canary readout, and stage count all adjust automatically since everything derives from STAGES.length and STAGES[stageIndex].