The public status pages (the ones your visitors see at impulseye.com/p/your-slug) were the last corner of the product still wearing the old look. This week we rebuilt all three layouts to match the rest of the site, added a live preview so you're not guessing what your customization choices actually look like, and turned up a genuine data bug along the way.
Same three layouts, new system
Classic, Bold, and Minimal still work the same way they always did — pick one, tune your colors, logo, headline, and which sections show. What changed is the skin: black background, sharp corners, one monospace typeface throughout, and your brand colors used as an actual gradient instead of two flat colors sitting next to each other with a hard seam down the middle. It sounds like a small thing until you see the seam.
/p/demo always renders a fully self-contained sample page — no login, no real monitor required — if you want to see the three layouts side by side.
A live preview, finally
Before this, customizing your status page meant picking a layout, colors, and a logo shape, saving, then opening the real page in a new tab to see if it looked right. Now the Appearance panel on a monitor's edit page renders the exact same component the public page uses, live, as you type. Change the layout, drag in a logo, flip a section toggle — the preview updates immediately, using the same code path a visitor actually sees.
That last part mattered more than it sounds. The preview and the real page share one component now, specifically so the two can never quietly drift apart — the classic failure mode where a settings preview looks right and the live page doesn't, or vice versa.
The bug: a chart that was lying about missing hours
While rebuilding the timeline chart, we noticed something odd on a higher-frequency monitor: the last-24-hours bar chart showed data for maybe half the day, with the rest rendered as flat "no data" gray. The monitor was fine. The checks existed. The chart just wasn't showing them.
The first suspect was an old, self-imposed row limit. The status page fetched recent checks to build that 24-hour chart, capped at 500 rows — plenty back when every plan checked every few minutes, not so plenty once a 30-second check interval can produce up to 2,880 checks a day. Worse, that query wasn't even scoped to the last 24 hours — it pulled from a much wider retention window (up to 14 days), so the 500 most recent rows could represent a few hours, not a full day.
So: scope the query to exactly the last 24 hours, and raise the limit to something generous — 3,000, comfortably above even the fastest plan's daily volume. Shipped it, checked it, the chart looked better. Not fixed. Better.
Supabase's PostgREST layer silently caps every response at a project-level maximum row count, independent of whatever .limit() the client actually asks for. On this project, that ceiling is 1,000. Asking for 3,000 rows back doesn't get you 3,000 — it gets you 1,000, no error, no warning, just fewer rows than requested. Any monitor doing more than 1,000 checks a day was still getting truncated; we'd just moved where the cutoff landed.
We'd actually run into this exact ceiling before, on the private dashboard, and fixed it there by moving the aggregation into the database. This time we reached for the client-side fix first anyway, because it looked like the same shape of bug we'd already seen (a hardcoded limit that used to be enough), and a familiar-looking bug makes the familiar-looking fix feel like the right one before you've actually confirmed it is.
A row limit that was generous for the traffic you had when you wrote it isn't a constant. And a bigger row limit is still a row limit — it's not the same thing as no cap.
The real fix: a Postgres function that aggregates check counts per hour in SQL and returns at most 24 rows — one per hour, not one per check. Twenty-four rows never comes close to any row cap, at any check frequency, ever. Verified against a monitor doing 10,000+ checks a day: every one of the 24 hours now shows its real count.
What's next
The status page redesign was scoped deliberately narrow this round — same layouts, same customization options, new skin plus the live preview. New metrics on the page itself (response-time history, an uptime calendar) are on the list for a future pass, tracked in the /changelog like everything else here.