ContinuumNexus
API uptime monitoring for small teams and solo devs
Hey Indie Hackers 👋
I’m Florian, a full‑time developer from Belgium building small SaaS projects on the side.
I started ContinuumNexus because APIs in my client projects kept failing silently and I only found out when someone complained. Existing tools felt either too basic (just ping checks) or too complex and expensive for a solo dev or small team.
I wanted a simple, focused tool I would actually use myself : monitor a few critical endpoints and get a clear email when something breaks. My goal is to turn this repeated pain into a small, reliable product that quietly does its job in the background.
Right now it’s an MVP focused on uptime checks + email alerts.
If you rely on APIs for your projects, I’d love to know: what’s the minimum monitoring you’d actually use (or pay for) ?
9 Comments
Had the same issue where API failures only showed up after users started complaining.
Simple ping checks miss partial failures; even a slow response or broken payload can still look “healthy” unless you validate what comes back.
For your use case, do you care more about uptime or catching degraded responses early?
That’s exactly the pain that pushed me to start this.
For the MVP I’m focusing on basic uptime + clear email alerts when checks fail, but my long‑term interest is definitely in catching degraded responses (slow, incorrect, partial) rather than just “is it up?”.
Curious for your experience: when you hit issues in the past, was it more often full downtime or “looks up but behaves wrong” type problems ?
Quick public-surface check: ContinuumNexus loads over HTTPS and already has HSTS, CSP, nosniff, frame protection, and referrer policy, which is good. The thing I would fix first is monitor semantics: HEAD requests to the homepage and /robots.txt return 405 while GET returns 200. A lot of uptime tooling uses HEAD as a cheap probe, so for an API-monitoring product that can create false failure signals unless you handle or document it. Also worth adding a real /.well-known/security.txt contact path.
This is super helpful, thank you for taking the time to look at it so closely.
You’re absolutely right about the
HEADsemantics, that’s a great catch, especially for something that lives in the monitoring space. I’ll fix the 405 on/and/robots.txtand make sure HEAD behaves consistently so external probes don’t get a false signal.Good call on
/.well-known/security.txtas well, I’ll add a proper contact path there. Appreciate this kind of feedback a lot, it’s exactly what I need at this stage.Nice work, this looks like a very useful tool for APIs that need reliable monitoring.
Thanks a lot, appreciate it !
Still early days, but the goal is exactly that : something small and reliable that devs can trust for their critical endpoints without going full enterprise.
If you’re using APIs heavily in your projects, I’d be curious what you currently do for monitoring.
One thing I'd be careful with:
The interesting question may not be what minimum monitoring people would pay for.
It may be what decision they're actually trying to avoid making when something breaks.
Those sound similar, but they can lead to very different product decisions, customer segments, and pricing assumptions.
I wouldn't make that call too quickly from early feedback alone.
This is a really good framing, thanks for pointing it out.
You’re right: “what would you pay for?” and “what decision are you trying to avoid when something breaks?” are not the same question at all. The second one goes much deeper into who I’m actually building for and what they’re afraid of (waking up to angry customers, firefighting in production, explaining outages to non‑technical people, etc.).
I’ll spend more time talking to users specifically about that angle instead of just feature/pricing checklists, it’s a great lens for the next iterations.
Possibly.
The reason I'd still be careful is that I don't think the interesting part is the lens itself.
I think there's a bigger decision sitting underneath it.
That's one of those things that can quietly shape who the product gets built for, which feedback ends up mattering most, and what conclusions get drawn from it.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.