Shipped PagePing: know when any page changes (email/Slack alerts)
Hey IH đź‘‹
I built PagePing — paste any public URL and get notified when the page content changes (diff + optional AI summary). No CSS selectors needed.
Main use cases:
- competitor pricing pages
- terms/policy updates
- feature pages
Stack: Next.js, Supabase, Creem, Resend, Vercel Cron.
Looking for a few early users / design partners.
Founding offer: at checkout enter FOUNDING9 → Starter ~$9/mo (first 50).
Would love feedback: which pages do you actually want to watch?
Also live on Product Hunt today — would love your feedback if you have a minute:
https://www.producthunt.com/products/pageping?utm_source=twitter&utm_medium=social
I’d treat monitor health as a separate problem from change significance.
For a monitoring product, “no change detected” and “I successfully checked the page and it didn’t change” must mean the same thing. A 403, timeout, anti-bot challenge, broken renderer, or selector/parser failure should never silently look like stability.
I’d give each monitor a small state machine:
healthy — last fetch succeeded
degraded — intermittent failures
unreachable — repeated fetch failures
changed — valid fetch with a meaningful diff
And expose at least:
last successful check
last attempted check
consecutive failures
HTTP/render result
last known content fingerprint
The interesting retention metric might then be less “how often users return” and more “what percentage of monitors remain trustworthy after 30 days.”
If someone uses PagePing for pricing or policy changes, one silent week caused by Cloudflare could be more damaging than ten noisy alerts.
Are you currently tracking monitor health separately from content-change detection?
This is excellent framing — and yes, silent failures are worse than noisy alerts for pricing/policy monitors.
Right now I separate them only partially: fetch failures set the monitor to an error state with last_error + last_checked_at, and successful fetches go through change detection. I don’t yet have a proper health state machine (healthy / degraded / unreachable) or consecutive-failure tracking exposed clearly in the UI.
Your point about “% of monitors still trustworthy after 30 days” is a much better retention metric than reopen rate. That’s going on the roadmap — especially distinguishing Cloudflare/403/timeouts from “no change.”
Curious: in your experience, what’s the minimum health signal users actually need day one — last success + consecutive failures, or the full state machine?
For day one, I’d keep the user-facing signal smaller than the full state machine.
The minimum I’d want to see is:
Then put the technical detail — 403, timeout, renderer failure, selector failure — behind the error state rather than making users interpret it constantly.
The important distinction is that “checked successfully 2 minutes ago, no change” feels very different from “last successful check was 3 days ago, 12 attempts have failed since.”
I’d still model healthy / degraded / unreachable internally, because that gives you clean transition rules and alerting later. But the UI can stay simple until users actually need the extra nuance.
So: simple trust signal on the surface, richer state machine underneath.
That’s the cleanest day-one design I’ve heard: simple trust signal on the surface, richer states underneath.
I’ll ship UI as healthy / having trouble + last success + consecutive failures, and keep 403 / timeout / render failures behind the error detail. Backend can still model healthy / degraded / unreachable for alerts.
“Last success 3 days ago, 12 failures” vs “checked 2 minutes ago” is exactly the trust gap I want to close. Thanks — this helped prioritize.
The three use cases are close technically, but potentially very different buying behaviors.
With the early users you’re looking for, are you mainly trying to discover which use case gets the strongest initial interest, or which one actually creates repeated monitoring behavior after someone sets up their first page?
Great distinction. Early on I’m optimizing for repeated monitoring behavior — if someone sets up a page and keeps coming back when it changes, that’s the real signal.
Use-case interest helps me write better messaging, but retention on the first monitor is what I’m watching most. Curious which of those two you’d prioritize first as a founder?
I’d probably be less interested in my preference and more in what the early behavior reveals.
It’ll be interesting to see whether the same use case that gets someone to set up the first monitor is also the one that creates a reason to keep checking back.
That’s the right frame. I’ll watch whether the first monitor they set up is also the one they reopen — that’s the real retention signal.
My hunch: competitor pricing/terms pages win early setup, but “pages that affect a deal or decision” create the habit. Going to track that and share what I learn.
That’s a useful hypothesis to test. The interesting part will be whether those pages actually produce repeat monitoring, rather than simply attracting the initial setup.
I’ll be interested to see whether the behavior supports that distinction once you have enough usage data.
Agreed — setup interest alone won’t prove it. Once I have enough usage, I’ll compare: which page types get the first monitor vs which ones get reopen / alert engagement.
Will share what the data shows. Appreciate you pushing on the distinction.
You’ve got a useful hypothesis here, and I’d be interested in hearing what the usage data shows once you have it. I’d also like to continue the conversation outside the thread if you’re open to it. What’s the best email to reach you on?
Happy to continue offline — best email is hello@page-ping.com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Clean execution, and "no CSS selectors needed" is the right wedge, that's the friction that kills every DIY version. But the make-or-break is your top use case: competitor pricing pages change constantly in trivial ways (A/B tests, copy tweaks, reordered FAQ). Alert on every diff and users drown and mute you within a week, same death as a stale spreadsheet, just louder.
So the real product isn't "detect changes," it's "detect changes that matter." The AI summary is your shot: if it says "price went up 10%" vs "reworded a heading" and only pings on the first, you're indispensable. If it just diffs everything, you're a commodity.
Do you let users filter by significance, or alert on any diff?
Really solid point — noise is the #1 risk with change monitoring.
Right now PagePing alerts on content diffs (so you see what actually changed). Significance filtering / “only alert on meaningful changes” is high on my list, especially for pages with A/B tests or frequent minor updates.
Would love to know: for your use case, would you rather filter by keyword/section, or by a “meaningful change” threshold?
They're not alternatives, they solve significance two ways: keyword/section is user-defined (I say what matters), AI threshold is inferred (you decide for me). That tells you the build order.
Start with keyword/section: deterministic, so users trust it. They said "watch the pricing table," a ping means that changed. An AI threshold is a black box, when it's silent the user can't tell if nothing happened or the AI missed it, and one missed price change kills trust in every future silence. Predictable-but-manual beats smart-but-opaque early.
For pricing pages specifically, is "meaningful" almost always numbers changing? If so, keyword on the price fields gets 90% there with zero AI risk.
This is a really clean build-order argument — and I agree.
Keyword/section first: deterministic, user-defined significance, easy to trust. AI threshold later as an optional layer, not the default. “Predictable-but-manual beats smart-but-opaque early” is exactly right, especially after one missed pricing change.
On pricing pages specifically: watching the price/plan block (or a few number-heavy sections) probably covers most of what people care about, with zero AI risk. That’s where I’ll start.
Quick context: I built this because I kept manually checking competitor pricing/terms pages every week.
Happy to set up 1–2 monitors for your real use case if anyone wants to try it.