Pulsekeep

Uptime monitoring for websites and APIs

Visit Website
December 28, 2025 Pulsekeep update: more regions, custom domains, and built-in status pages

Shipped a few solid improvements to Pulsekeep this week:

  • More monitoring regions
    Expanded region coverage so checks are less sensitive to single-region blips and routing issues.

  • Improved custom domain support
    Cleaner setup + better SSL handling for people running monitors or status pages on their own domains.

  • Built-in status pages
    Every project can now have its own public status page — no extra tools needed.
    Designed to be simple, fast, and readable (not a wall of charts).

Still focused on the same goal:
alerts that mean real downtime, not noise.

Would love feedback from anyone running production systems or on-call a bit too often 🙂

Comment

December 27, 2025 Why I built Pulsekeep after missing real downtime

I built Pulsekeep because I missed real production downtime — more than once.

Not because monitoring wasn’t in place, but because:

  • alerts were delayed

  • one region flapped and triggered noise

  • real incidents were buried in dashboards I wasn’t watching

Most uptime tools optimize for features and charts.
I wanted something that optimizes for speed and signal.

So Pulsekeep does one thing:
Detect outages fast, confirm them across regions, and alert only when it actually matters.

Recently I shipped multi-region checks, and the hardest part wasn’t infra — it was defining what “down” really means.
One failing region shouldn’t wake you up.
Consensus > single probes.

Still early (MVP), still iterating, but the principle is fixed:
If everything is up, you shouldn’t hear from us.

Happy to share implementation details or get feedback from anyone running global apps

1 Comment

About

I built Pulsekeep after missing real downtime because alerts were delayed, noisy, or buried in dashboards. Most uptime tools optimize for features and charts, not fast, reliable alerts. Pulsekeep exists to do one thing