UptimeEye
Know the moment your app breaks
Start new thread

UptimeEye - Your homepage is up. Your checkout might not be.

by•
Ping monitors say "all good" while your login, checkout or API flow is silently broken. UptimeEye runs your real user flows every 30 seconds — multi-step checks, cron job monitoring, status pages, instant alerts. EU-hosted, free tier included.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt! 👋 We launched UptimeEye here 11 months ago as a beta. It got a grand total of 7 upvotes - but also a handful of users who stuck around, sent us feedback almost daily, and shaped what the product is today. So we're back, properly this time. The problem we care about: classic uptime monitors ping your homepage and report "200 OK" - while your login, your checkout, or your API quietly stopped working. The homepage was never the thing that breaks. We run a handful of small SaaS products ourselves, and our wake-up call wasn't even an outage. A nightly job on one of them - the one that sends users their weekly plan - just stopped running after a config change. No error, no crash, no alert. Uptime monitor: green. Users noticed before we did. Ping monitors can't see the things that are supposed to happen but don't - that was the day we stopped trusting green dashboards and started building UptimeEye, with cron jobs and scheduled tasks as first-class citizens. What UptimeEye does instead: 🔗 Multi-step checks - chain requests, pass variables between steps, store API keys as encrypted secrets, assert on status, latency or response body. Your entire signup flow becomes one check, running every 30 seconds. ⏰ Cron job monitoring - your nightly backup job doesn't check in within its grace period? You get paged. 📄 Status pages - public, with email subscribers. Agencies can white-label them and put them on their client's own domain. 🔔 Alerts where you work - Slack, Discord, Telegram, MS Teams, PagerDuty, email, webhooks. 🇪🇺 EU-hosted and GDPR-friendly, built by a small team in Germany. What changed since the beta: we rebuilt onboarding (first monitor in ~5 minutes), added incident reports, status page subscribers, white-labeling, custom domains, a proper free tier, and simple pricing (Free / €29 / €79). For the Product Hunt community: 50% off your first 3 months of Pro or Agency with code PHUNT50 - valid for a week after launch. We'll be here all day. Question for you: what's the worst outage a ping monitor didn't catch for you? Best story gets our eternal sympathy.

One thing I'd love to see is a status page widget you can embed on customer-facing dashboards, so end users can see real-time uptime without bothering support. Would make the alerting loop feel even more proactive.

Maker

 Love this idea. Good news: UptimeEye already includes an embeddable status page widget for exactly this use case. You can add real-time status directly to a customer-facing dashboard, so users don’t have to visit a separate status page.  

   

 Your comment is also useful feedback for us: we clearly need to make this feature more visible. Would love to hear what kind of dashboard or product you’d embed it into.

love how the 30 second check interval is front and center on the landing page. honestly that detail tells me the team actually builds for devs who care about catching stuff before it becomes a fire, not just checking a feature box.

Maker

 Thanks, Gözde! That was very intentional. When something critical breaks, the difference between checking every few minutes and every 30 seconds can mean finding out before users start opening support tickets. We wanted that to be clear immediately rather than buried somewhere in a feature list.

The dashboard layout here is genuinely clean, no clutter, no upsell tiles fighting for attention. That kind of restraint is rare in monitoring tools and makes a real difference when you're triaging at 2am.

The 30-second checks are genuinely fast, and the alert flow feels clean without burying you in settings. Wish I'd had this during that last API incident.

Maker

 Thanks, Gökhan!  

   

 Out of curiosity, what happened during that API incident - was the endpoint completely down, or was it still responding but returning the wrong data? The second case is exactly where we see basic ping monitors miss problems.