Velprove

A 200 OK on / doesn't mean your users can sign in. Velprove tests the login, the API journey, and the dashboard from 5 regions. Free plan, no credit card.

Comment

Inspiration

I kept running into the same problem while managing my own deploys. Every uptime tool I tried would ping the homepage, get a 200 OK, and report everything healthy, even when the real product was broken. The login flow could fail, API auth could expire, or the dashboard could hang forever, and the monitor would still stay green.

A successful response from / does not mean a user can actually use your app. I wanted monitoring that tested the things my users were trying to do.

What it does

Velprove monitors uptime by behaving like a real user, not by polling URLs.

It signs into your app in a real browser, walks through multi-step API flows, and runs checks from five global regions: North America, Europe, UK, Asia, and Oceania. When something breaks, you hear about it before your users do.

Browser login monitors, API monitors, SSL expiry alerts, public status pages, and incident alerts are included. There is a free plan with no credit card required.

How I built it

  • App layer: Next.js and TypeScript, deployed blue-green behind Cloudflare Load Balancer.
  • Worker layer: Fastify, Playwright, and BullMQ workers distributed across five regions, each consuming jobs from its own regional Redis queue.
  • Data layer: PostgreSQL high availability via Patroni backed by a three-node etcd cluster, plus Redis with Sentinel quorum.
  • Edge and operations: Cloudflare tunnels for ingress, VictoriaLogs as the centralized log sink, and a Bash deployment pipeline with behavioral safety gates.

Challenges I ran into

  • Cookie banners break browser monitors. After GDPR, most sites intercept login clicks with consent modals. The “log in like a real user” pitch was meaningless until I added pre-login actions to dismiss them reliably.
  • HA infrastructure has failure modes of its own. Twice in one month, Ubuntu unattended-upgrades pulled shared library updates, needrestart automatically restarted Patroni, and the cluster performed an unexpected leader switch. Some check results were lost in flight. The fix was a per-service needrestart override plus package blacklists, accepting that some security updates now wait for scheduled maintenance windows.
  • Multi-step monitors need strict boundaries. Each step executes once in sequence. There is no polling, retry-until-success, or freshness validation. Only six assertion types exist. I had to keep both the product and documentation honest instead of inventing features that sounded more powerful than they really were.

Accomplishments I'm proud of

  • A three-node etcd cluster holding roughly 3 MB across all members, tightly defragmented with jittered daily snapshots.
  • A production health script that completes in about seven seconds while collecting signals across the app layer, workers, PostgreSQL, Redis, monitors, Cloudflare tunnels, worker authentication, recent errors, and logging anomalies.
  • An open SLA dataset covering AWS, GCP, Azure, Cloudflare, and Vercel, published as machine-readable JSON.
  • Three free uptime calculators launched without email gates: SLA percentage, downtime cost, and SLA credit calculators.
  • A publishing pipeline that routes every article through trend research, SEO review, fact checking, reality validation, OG regeneration, and Stage 7 verification before deployment.

What I learned

  • Centralized logging with VictoriaLogs beats SSH-sweeping every time. One LogSQL query across _HOSTNAME patterns answers questions that used to require multiple terminals and manual correlation.
  • Behavioral nudges in deployment tooling prevent more incidents than post-mortems. Warnings for risky deploy timing or missing rollback plans catch mistakes before they happen.
  • “Working” uptime monitoring and “honest” uptime monitoring are different products. The temptation to invent impressive-sounding capabilities in marketing copy is constant. Saying no to misleading claims is harder than writing the feature itself.

What's next for Velprove

  • Pre-login browser actions: Dismiss cookie banners, set cookies, or click selectors before the username/password sequence begins. The feature is fully specced and waiting for either the first customer request or a scheduled development cycle.

Built With

Share this project:

Updates