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 cause was an old, self-imposed row limit. The status page fetches recent checks to build that 24-hour chart, and the query was capped at 500 rows — a number that was plenty back when every plan checked every few minutes. It stopped being plenty once higher-frequency checking existed:
- A 30-second check interval produces up to 2,880 checks a day.
- That query wasn't scoped to the last 24 hours either — 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.
- Net result: the chart silently truncated to whatever the most recent 500 checks happened to cover, and quietly back-filled the rest of the day as empty.
A row limit that was generous for the traffic you had when you wrote it isn't a constant. It's a number that ages.
The fix was a dedicated query, scoped to exactly the last 24 hours with a limit generous enough to cover even the fastest plan with headroom — instead of relying on the same wide, capped fetch used for the longer-window uptime percentage. Two different jobs, so now they get two different queries instead of sharing one that only really worked for one of them.
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.