webdevpuneet.com

Related Snippets

144 in Dashboards category
1–6 of 60

Metric KPI Card Grid

Interact.js Draggable and Resizable Dashboard Panels with Snapping

Dragula Copy vs Move Lists with Spill Control

SortableJS Shared Groups: Clone from a Palette into a Page Builder

SortableJS Drag Handle with Pinned and Locked Rows

SortableJS Nested Sortable Tree with Keyboard Controls

DNS Propagation Checker Widget — Free HTML CSS JS Snippet

DNS Propagation Checker Widget · Dashboards · Plain HTML, CSS & JS · Live preview

CategoryDashboards
TagsCSS AnimationDashboard UI

Copy & paste

Source Code

<div class="demo">
  <div class="tile">
    <div class="tile-head">
      <div>
        <h3>DNS propagation</h3>
        <p class="record-line"><span class="record-type">A</span> app.example.com <span class="arrow">&rarr;</span> 203.0.113.42</p>
      </div>
      <button class="recheck-btn" id="recheckBtn">Recheck</button>
    </div>

    <div class="progress-row">
      <div class="progress-bar"><div class="progress-fill" id="progressFill"></div></div>
      <span class="progress-text" id="progressText">0 / 8 resolvers</span>
    </div>

    <ul class="resolver-list" id="resolverList"></ul>
  </div>
</div>

Extend with AI

Take This Snippet Further With AI

The AI prompt for this one is for Patreon supporters ($3 a month), along with a site with no ads. Supporters enter the passcode once and it is remembered in this browser.

· Become a supporter

What's included

Features

Eight named global DNS resolvers checked with individually staggered, realistic delays rather than all at once
Pulsing dot animation clearly signals a resolver is still pending versus already resolved
Live progress bar and count update as each resolver independently completes
Bar and text switch to a distinct green "fully propagated" treatment only once every resolver is done
Recheck button cancels in-flight timers before restarting to avoid overlapping or double-counted runs
Recheck button disables itself for the duration of a check to prevent concurrent requests
Resolver rows fade and rise into view using a two-step requestAnimationFrame reveal
Structured to swap the simulated delays for real DNS-over-HTTPS lookups with minimal changes

About this UI Snippet

DNS Propagation Checker Widget — Staggered Resolver Checks & Live Progress Bar

Screenshot of the DNS Propagation Checker Widget snippet rendered live

After changing a DNS record, the honest answer to "is it live yet" is "it depends which resolver you ask" — propagation isn't instantaneous or uniform, it trickles out across the world's DNS resolvers over minutes to hours depending on TTLs and caching. This widget models that reality directly: instead of a single pass/fail check, it queries a list of named global resolvers one at a time with staggered, realistic delays, letting each one settle into a "resolved" state independently while an overall progress bar tracks how much of the world has caught up.

Staggered delays that mimic real geographic variance

Each resolver object carries its own delay value in RESOLVERS, deliberately spread from 600ms (Google's well-connected Iowa infrastructure) to 4100ms (a resolver on the other side of the world) rather than resolving all eight simultaneously. runCheck() schedules one setTimeout per resolver at its own delay, so the list visibly fills in from nearest/fastest to farthest/slowest — the same pattern a real propagation check exhibits, where nearby resolvers with recently-refreshed caches often update well before ones on a different continent.

A pulsing dot signals "still checking," not silence

Rows in the pending state get a resolver-dot with a pulse keyframe animation (opacity oscillating via animation: pulse 1s ease-in-out infinite), giving each unresolved row a subtle heartbeat that communicates "this is actively being checked" rather than looking stalled or broken while its timer counts down. Once a resolver's timer fires, the dot switches to solid green and the pulse animation implicitly stops (since .propagated no longer carries the pending class that triggers it).

Progress text and bar color both shift at full completion

updateProgress() writes a "X / Y resolvers" count that, only once done === total, appends " — fully propagated" and swaps the bar's gradient from indigo-purple to green via a .complete class — a single extra piece of state (full completion) gets its own distinct visual treatment rather than the bar simply reaching 100% width in the same color it always was, making the "done" moment more noticeable at a glance.

Recheck cancels in-flight timers before restarting

Clicking #recheckBtn calls timers.forEach(clearTimeout) before scheduling a fresh batch — without this, clicking recheck mid-check would leave the previous run's timers still pending, potentially firing state updates against rows that buildRows() had already replaced, or double-counting doneCount from two overlapping runs. The button also disables itself for the duration of a check, since a real DNS lookup service would reasonably rate-limit or simply be unable to serve overlapping check requests from the same client.

Row entrance uses a fade-and-rise reveal, not an instant list swap

buildRows() inserts all rows with opacity: 0 and adds the .shown class inside a requestAnimationFrame callback, the same two-step technique used elsewhere in this library to guarantee the initial hidden state actually paints before the transition to visible begins — otherwise the browser could coalesce both style writes and skip the fade-in entirely.

Step by step

How to Use

  1. 1
    Watch resolvers resolve one at a timeEach resolver row switches from a pulsing "Checking" state to a solid green "Resolved" state at its own staggered delay, simulating real-world propagation timing.
  2. 2
    Watch the progress bar and textThe bar fills and the count updates as each resolver completes, turning green with a "fully propagated" label once all resolvers are done.
  3. 3
    Click "Recheck"Cancels any in-flight timers, rebuilds the resolver list, and reruns the staggered check from the start — the button disables itself for the duration.
  4. 4
    Replace the record being checkedUpdate the record type, hostname, and target value shown in the header .record-line.
  5. 5
    Replace RESOLVERS with real lookupsSwap the setTimeout-based simulation for real DNS-over-HTTPS queries (for example via Cloudflare's or Google's DoH endpoints) against each named resolver, updating each row when its real response returns.
  6. 6
    Export in your formatClick "HTML" for a standalone file, "JSX" for a React component, or "Tailwind" for a Tailwind CSS version.

Real-world uses

Common Use Cases

OPS
DevOps and infrastructure dashboards
Give an engineer who just changed a DNS record a live view of how far propagation has reached instead of manually running dig or nslookup against a list of resolvers.
Domain registrar and DNS management tools
Surface this after a customer updates a record in a registrar's control panel, replacing a static "changes may take up to 48 hours" disclaimer with a live check.
ALERT
Migration and cutover status pages
Pair with an SSL Certificate Expiry Monitor style widget during a domain or hosting migration to track both DNS and certificate readiness at once.
CDN and DNS provider status tools
CDN providers that let customers point custom domains at their edge network can use this pattern to confirm a customer's CNAME or A record has propagated before enabling traffic.
Learn staggered-timer simulation patterns
A clean example of simulating variable-latency parallel operations with individually staggered setTimeout calls and proper cleanup on retry, useful for any "check multiple sources" UI.

Got questions?

Frequently Asked Questions

No — RESOLVERS is a static demo array and each resolver "resolves" after a fixed setTimeout delay rather than performing a real network lookup. For production use, replace the timers with real DNS-over-HTTPS queries (Cloudflare's or Google's DoH endpoints, for example) issued to each named resolver and update each row when its actual response arrives.

Each resolver object in RESOLVERS carries its own delay value, deliberately varied to mimic how real DNS propagation is uneven across the world — a nearby, well-connected resolver typically shows an updated record before a resolver on another continent with a different cache refresh schedule.

The button is disabled for the duration of a check, so this cannot happen through the UI. Internally, runCheck() also clears every previously scheduled timer via timers.forEach(clearTimeout) before starting a new batch, which prevents a stale in-flight run from firing state updates after a fresh check has already rebuilt the resolver list.

Rows with the pending class include a resolver-dot element with a CSS animation: pulse 1s ease-in-out infinite rule that oscillates its opacity. Once a resolver's timer fires, the row loses the pending class and gains propagated, which switches the dot to a solid green fill with no animation, visually distinguishing "still checking" from "confirmed resolved."

updateProgress() only adds the .complete class — which swaps the bar's gradient from indigo-purple to green — once the done count equals the total resolver count. Reserving the fully-complete color exclusively for the fully-complete state makes that specific moment stand out more clearly than if the bar simply approached 100% in its normal color.

Add or remove objects in the RESOLVERS array, each with a name, loc, ip, and delay. The row-building, progress-counting, and staggered-timer logic all iterate over this array directly, so no other code changes are needed to change the resolver count.