2
5 Comments

I built an uptime monitor that checks what your API actually returns, not just the status code

After 10 years as a frontend engineer, I kept hitting the same blind spot
on every project: we monitored whether servers were up, but never whether
our APIs actually returned the right thing.

A 200 OK tells you almost nothing. The endpoint can return an empty body,
a malformed payload, or an error wrapped inside a successful response —
and every uptime tool I tried would happily report everything as green.

So I spent four months building ApiPulse, solo. Angular on the front,
Node/Express + Postgres on the back, Paddle for payments.

What makes it different from the big players:
— Multi-step monitors with assertions: check status code, body contains /
doesn't contain, response time thresholds, header existence
— SSL certificate expiry alerts
— Public status pages you can brand (logo, colors, custom message)
— Email + Slack alerts, but only on status transitions, not every check

Free plan gives you 3 monitors. Starter is $5/mo for 20, Pro is $9/mo for
unlimited with 1-minute intervals.

It went live this week. First real payment came through today, which was
a strange feeling after months of building in the dark.

Happy to answer anything about the build, the stack, or why I picked
Paddle over Stripe.

, Founder of Icon for ApiPulse
ApiPulse
on September 14, 2026
  1. 1

    The first payment is the interesting signal here because it moves this beyond a purely technical launch. Do you know what specifically convinced that customer to pay—the response assertions, multi-step checks, or simply wanting another reliable monitor?

    1. 1

      Honest answer: that first payment was me. I ran a real €5 checkout through
      my own card to verify the full payment chain end to end — and good thing I
      did, because the webhook silently failed and the plan never activated. Took
      an hour to find out the webhook secret in my env vars had been truncated on
      copy-paste.

      So no real customers yet. Launched today.

      But your question is the one I actually want answered. My bet is on the
      response assertions — a 200 OK with a broken body is the failure mode that
      bit me repeatedly over 10 years, and most tools don't catch it. Multi-step
      checks feel more niche.

      I could be wrong though, which is why I'm here rather than buying ads. If
      you run APIs in production, I'd genuinely like to know which of those three
      would matter to you.

      1. 1

        The response-assertion hypothesis is much more concrete than the payment signal itself. If you’re open to it, what’s the best email to reach you on?

        1. 1

          Happy to — what did you have in mind? Just so I know whether this is about
          the monitoring side or something else.

          I don't have a public address up yet (setting that up tomorrow), but I'm
          easy to reach through the site once it's live.

          1. 1

            It’s about the monitoring side — mainly how you’re thinking about validating whether response assertions are actually the reason production users would choose ApiPulse. No rush on email; once you have an address set up, we can continue there.