Our startup was losing users silently for 6 hours - no alert fired. Here's what we built
Most monitoring tools tell you when your server goes down.
Nobody tells you when:
- Signups stopped at 2am - server was fine
- Payment initiated but never completed
- Cron job ran but processed zero records
- Stripe webhooks queued and silently stopped retrying
- AI agent looped for 3 hours burning API credits
- AI agent got stuck waiting on a tool call - never failed, never finished
- One of your 5 clients' data pipelines went quiet while the others ran fine
- Server 2 stopped processing while Server 1 looked healthy
We hit several of these on our own product. None triggered a single alert.
So we built NotiLens: it learns your normal baseline and alerts you when things go abnormally quiet. No manual thresholds. No dashboard to stare at.
Built for solo founders, small teams, and anyone running multiple AI agents or serving multiple clients across separate systems.
Offering 3 months free to the first 10 early users in exchange for honest feedback. 2 spots already taken.
Trending on Indie Hackers
"No alert fired" is the exact common thread across the SaaS failures I keep hearing about. Infrastructure goes down, alerts fire. Payment fails, almost nothing fires.
The Stripe dashboard shows a failed charge. But your customer doesn't know, you don't have a sequence running, and by the time anything happens the card has expired or they've moved on. No alert. No recovery. Just silent churn that shows up in MRR 30 days later.
I built RecoveryMRR to close this specific gap: automated Stripe payment recovery with a Day 0 response in the first hour after a failure, Day 3 follow up, Day 7 final attempt. Flat $99 per month via Stripe OAuth. Setup is about 4 minutes.
If you're seeing silent churn that traces back to payment failures, I can show you exactly what the sequence looks like over a quick Loom.
This is close to the AI workflow problem I’m researching as a UX/UI designer + full-stack developer.
The “quiet failure” framing feels strong because it skips the dashboard entirely and starts from the operational risk. The question I keep coming back to is what makes the alert trustworthy enough to act on.
For example, if an AI agent says “activation has gone abnormally quiet,” I’d want to see the metric definition, baseline window, affected segment/client, and data gaps before trusting the next action.
Are your early users asking more for detection, or for explanation of why the quiet period matters?
great question and honestly one we're still working through.
early users are asking for both but in sequence - detection first, then explanation. if the alert isn't trustworthy enough to act on, explanation doesn't matter.
what's built the most trust so far: showing the baseline window, what's normal for that specific client or flow, and how far current behavior deviates. each topic and event is isolated so one client's pipeline going quiet reads separately from the rest.
on data gaps - we handle ingestion delay, so the alert accounts for lag before firing. still rough on edge cases but it's not just raw silence detection.
baseline is ML-learned automatically, but you can also set manual thresholds if you know what normal looks like for a specific flow.
curious what patterns you're seeing in your research on this.
The distinction I keep coming back to is silence detection vs explicit outcome proof.
Baseline learning seems really useful when there is enough normal traffic to compare against. The harder case, at least for small SaaS, is the low-volume workflow where “normal” is sparse: a weekly report, a billing sync, a support import, an AI job that only runs overnight.
For those, I’d still want the workflow itself to emit evidence like “completed, processed 42 records, delivered artifact X” and alert when that evidence is missing, stale, or says zero when zero is suspicious.
I’m exploring that explicit evidence layer with Luota, so I’m biased, but I think these are complementary: anomaly/silence detection for patterns, outcome proof for workflows where the expected result is known.
Curious how you handle brand-new or low-volume workflows before the baseline is reliable?
Right distinction. For low-volume workflows like weekly sync, overnight AI job - ML baseline doesn't have enough signal. So we lean on explicit outcome proof: started, completed, records processed. If the expected evidence doesn't arrive by the known deadline, that's the alert. No baseline needed. Both layers run together - pattern detection for high-frequency events, explicit proof for low-volume workflows where the result is known.
The 'silent failure' pattern is brutal because the signal is absence, not presence. No error, no spike, no alert - just a slow bleed.
The fix you built (monitoring for what should happen, not just what shouldn't) is the right frame. For solo founders this applies to business ops too: most don't have alerts for client drift, stalled projects, or decisions that should have been revisited weeks ago. The absence of a problem signal isn't the same as the presence of health.
What's your current stack for the monitoring layer? Curious how lean you kept it for a small team.
'The absence of a problem signal isn't the same as the presence of health' that's the line most monitoring tools are built on the wrong side of. On the stack question, we built NotiLens around this exact problem. Kept it as lean as possible: send us the business events that should be happening, we watch the frequency, metric values, and response patterns against your baseline - alert when something goes quiet, deviates in value, or slows down abnormally. No dashboards to maintain, no threshold configs to babysit. The client drift and stalled project examples you mention are exactly the same pattern - expected activity with an expected frequency and expected shape. When it stops, slows, or drifts - that's the signal.
This is a familiar story. The invisible churn problem is one of the most dangerous because it looks like plateau instead of decline in your metrics.
The 6-hour detection window you mention is still fast compared to most. The real fix, as you figured out, is behavioral alerts rather than just error alerts — watching for "unexpected silence" from active users rather than just exceptions. Did you consider using cohort-based baselines (e.g., this user type typically does X within Y hours) to set the thresholds, or did you go with absolute thresholds?
We went with per-event ML baseline learning as the primary layer - day-of-week and time-of-day factored in, each event learns its own pattern independently. On top of that you can add manual rules for specific conditions - silence windows like "no events in 1 hour" or metric rules like "order value greater than 500." So technically closer to absolute for those specific cases, but the ML baseline handles the pattern detection that static thresholds miss. The cohort-based approach is interesting for user behavior but for business event monitoring the baseline needs to reflect your traffic rhythm. Both approaches are watching the right thing: the gap between expected and observed, not just error rates.
How does NotiLens handle products that are still in early growth stages, where "normal" is shifting week over week and the baseline itself hasn't stabilized? Just curious about your ICP. The solo founder whose traffic patterns are genuinely inconsistent seems also the one most likely to need this kind of monitoring because I definitely don't have an ops team watching dashboards.
That's the core design challenge and honestly the most common early user situation. The ML baseline adapts as your patterns shift - it's not a fixed window, it's a rolling one. So if you're growing 20% week over week, the baseline grows with you. Where it gets harder is truly erratic traffic - a viral spike one week, dead the next. For that we have manual silence windows as a fallback - you set "I expect at least one signup every 24 hours" and that holds regardless of what the ML is still learning. Both run simultaneously so you're never flying blind even in week one. Early on there will be occasional false signals while the baseline is still learning. We can't eliminate that entirely, but they taper off quickly as the pattern stabilizes.
The solo founder and small teams who we built this for - no ops team, no one watching dashboards, just a system that notices when something that should be happening quietly stops. Also useful if you're running AI agents - a looping or stuck agent won't throw an error but NotiLens will catch it. Would love to connect and see how it fits your stack - happy to offer 3 months free. Reach out at notilens.com/contact
Great concept!
Just one thought - how much sensitive & secure data access does it require to reliably monitor, and how does limiting the access affect the performance?
Many companies keep their revenue records private, can NotiLens understand their "baseline" with public data only?
NotiLens stores minimum data from third-party integrations - for example from Stripe: event type, payment status, currency, amount, location, and timestamps. No card numbers, no CVV, no full customer PII. Same principle applies across all integrations - Shopify, GitHub, and others - only the fields needed for anomaly detection and baseline learning are stored. For custom events you instrument yourself, you have full control over what metric data you pass - you decide exactly what NotiLens sees. Data is used purely for detection, not shared or sold.
Exactly.
That answer will tell you more than any homepage feedback.
If users repeat “silent failure” back naturally, the category is landing.
If they still say “monitoring,” the site is explaining it but the product is not owning it yet.
That’s the signal I’d watch closely.
Had this exact failure mode three weeks ago. An agent I had running overnight got into a retry loop where it kept failing one tool call, suppressed the error in its own scratchpad, and reported "task complete" at the end. Process was alive, exit code clean, dashboard green. Lost two days of state because the next morning's run inherited the broken plan as if it were ground truth. The new monitoring layer for agents needs to watch the plan, not just the process. "Did the agent actually do the thing it said it did" is a different question than "is the agent running."
"Did the agent actually do the thing it said it did" that's the sharpest framing I've seen. Exit code clean, dashboard green, task "complete" but output was wrong and the next run inherited broken state as ground truth. This is exactly what output metric monitoring catches - if that agent normally processes 500 records and suddenly reports 2, that's an anomaly. But also the reverse- normally 50 records at 2am Tuesday, suddenly 500 - suspicious even though 500 is a valid number. Or the agent completes with the exact same output count but takes 45 minutes instead of the usual 3 - duration deviated while everything else looked normal. Or confidence scores that normally sit between 0.85 and 0.95 suddenly spike to 0.99 across every output - technically valid, but way outside the normal range and worth investigating. Process health told you nothing. Output metrics, timing, and value distribution tell you where to look.
The duration deviation example is a good one - same output count,
45 minutes instead of 3, everything else looks normal. That's
exactly the kind of thing you'd never catch with threshold checks.
You need a baseline to compare against.
The confidence score spike is even sneakier. 0.99 across the board
sounds great until you realize the model probably stopped
discriminating and is just rubber-stamping everything. Technically
passing, practically broken.
Exactly - 0.99 confidence across the board is the model equivalent of a cron job that runs but processes nothing. Technically successful, practically broken. The signal isn't the absolute value, it's the deviation from the pattern. A model that normally distributes confidence scores between 0.85 and 0.95 with natural variance, suddenly flat-lining at 0.99 with no variance - that's the anomaly. The distribution collapsed, not the output. That's what baseline monitoring catches that threshold checks never will.
'Distribution collapsed, not output' is the cleaner phrasing - I'm stealing it. Threshold checks assume the failure mode is value, when 80% of model failures are shape: variance disappears, latency tails flatten, error class becomes uniform. The cron-with-no-work analogy works because in both cases the green dashboard is the bug, not the proof. Most teams will need an incident to learn this.
"Most teams will need an incident to learn this" and the incident is always more expensive than the monitoring would have been. The deviation was there before the disaster. Nobody was watching the shape.
That's exactly what we built for - catch the deviation before it becomes the incident.
The leading-indicator framing is the right anchor for the pitch. The hard part is that monitoring spend is judged against the cost of last quarter's silence, not next quarter's avoided disaster. Buyers don't have a budget line for 'shape detection' yet. Teams that adopt this layer first usually have a recent incident scar, which is why the category compounds slowly. You may need a sharper opening claim than 'catch the deviation' buyers can already hear that as 'monitoring 2.0.'
The category does compound slowly because the pain is invisible until it isn't. On the sharper opening claim, you're right that "catch the deviation" is too easy to hear as monitoring 2.0. The frame we're testing is "catch silent business failure before your users do" - less about the mechanism, more about who finds out first. Curious whether that lands differently to you or still sounds like the same category.
The 'who finds out first' framing lands sharper. The mechanism framing puts the buyer in the monitoring category by default. 'Before your users do' puts them in incident-prevention - a different mental category. One thing to watch: it can pattern-match to status-page tooling for buyers who think they've solved that. The real differentiator is probably 'the silent kind that status pages wouldn't have caught.'
'The silent kind that status pages wouldn't have caught' that's the line. Status pages tell you the server is down. This catches the failures that happen while the status page stays green. That's the distinction that matters and the one that's hardest to explain until someone's lived it.
The "Stripe webhooks queued and silently stopped
retrying" one hit hard.
That's exactly how failed payments become silent
churn no alert, no recovery, just MRR quietly
disappearing.
Built Rescuely to catch the payment side of this
problem. Looks like NotiLens catches the
infrastructure side. Different layers of the
same silent failure problem.
Congrats on the launch the baseline learning
approach is smart. How long does it take to
establish a reliable baseline for a new user?
Rescuely and NotiLens are genuinely complementary - you catch the payment recovery side, we catch the silence side. On your question, baseline starts forming from day one and gets reliable within 7-14 days of normal traffic. Early on the ML is more conservative - widens the anomaly threshold until it has enough data to tighten it. First week you might miss edge cases, by week two it's catching the real signals.
7-14 days to a reliable baseline is actually
really reasonable for ML-based anomaly detection.
The conservative early threshold makes sense
better to miss edge cases week one than to
flood a new user with false positives before
trust is established.
Rescuely takes a similar approach with churn
scoring the score gets more accurate as more
payment history accumulates per customer.
Would genuinely love to explore a partnership.
Same customer, complementary problems. DM me?
Sounds good
Six hours is brutal - that's basically a full work session of your app being broken without anyone knowing. Curious what you ended up building for the alerting layer?
Alerts come through the NotiLens app - iOS and Android push notifications with custom sounds for different alert types, so you know at 2am whether it's critical or a warning before you even pick up your phone. The delivery layer is the straightforward part. The hard part was the detection - knowing that six hours of silence is abnormal for a Tuesday 2am specifically, without manually configuring that threshold. That's what took the most work to get right.
The AI agent examples are the most interesting category here. An agent that loops indefinitely or hangs on a tool call will never trigger traditional monitoring because it is technically running and not erroring. You need something that understands expected completion time and expected token spend, not just process health. That is a genuinely new class of monitoring problem.
Exactly right. it's a genuinely new class of problem. Process health tells you nothing about whether an agent is doing useful work. Expected completion time and expected token spend per run are the two signals that actually matter. That's exactly what we watch.
Error detection and silence detection are two different problems. Most tools handle loud failures fine. Silent failures are harder because they require knowing what normal looks like. A cron job that runs but processes zero records never throws an error. The AI agent looping forever case is the sharpest one in here. That problem is new and getting worse as more founders run autonomous agents.
This is way more painful than downtime tbh. Silent failures are the worst because everything “looks fine” until you realize you lost hours (or revenue). Curious how you define “normal baseline” early on with low data?
Good question - early on with low data the ML is more conservative, widens the anomaly window until it has enough signal to tighten it. You can also set a manual silence window as a fallback while the baseline learns, so you're not flying blind in week one. Both options run simultaneously.
This is interesting especially for distributed systems where partial failures don’t surface clearly. Monitoring baselines instead of thresholds seems like the right direction. We've been seeing similar needs while working on builds at FoundersBar: https://foundersbar.com
Distributed systems are exactly where this hurts most - partial failures are the hardest to catch because everything technically "works." Appreciate the comment.
Hi Stephen,
Really like the positioning behind NotiLens — especially the idea of detecting when systems go “abnormally quiet” instead of only looking for hard failures. That’s a very real pain point for AI agents and automation workflows.
I’m building ValueConn — a platform where digital products, operational playbooks, templates, and technical ecosystems can scale through team-based distribution rather than only direct sales.
Others can help distribute your assets, build teams around them, and revenue sharing + global payouts are handled automatically.
Given the kind of operational knowledge and workflows you’re building around AI systems, thought this might be relevant.
Happy to send a short breakdown if interested.
Kind regards,
Wen
Appreciate the kind words on NotiLens. Not the right fit right now but good luck with ValueConn.
Thank you.
This is the part of monitoring most people don’t realize until production:
The hardest outages are often the ones where nothing technically “breaks.”
200 OK responses.
Healthy CPU.
Healthy memory.
Healthy uptime.
Meanwhile:
From the outside, the system looks healthy.
But the business isn’t.
I ran into similar problems while building Sentinel. It completely changed how I think about “uptime monitoring.”
The real challenge isn’t detecting failure.
It’s detecting loss of function before users notice.
Exactly. "Loss of function" is the right framing and it's completely invisible to infrastructure monitoring. What's your approach to detecting it?
A big part of my approach has been breaking the request lifecycle into phases instead of treating response time as a single number.
I recently added separate timing metrics for:
That’s been interesting because you start seeing degradation patterns before a service is actually “down.”
For example:
The system may technically still be up, but the user experience is already deteriorating.
That gray area between healthy and broken feels massively under-monitored.
The degradation curve before actual failure - that's the real signal. We found the same pattern exists at the business layer. Signups slow before they stop. Webhook processing degrades before it fails. Same gray area, different layer.
What stands out in this story is how often these “silent failures” happen without any signal until it’s already too late — users don’t complain, they just drift away, and dashboards only tell you after the damage is done. We’ve seen the same pattern in SaaS where everything looks fine on the surface but one weak point in onboarding or messaging quietly bleeds retention because users never fully lock in the value, they just lose confidence and stop showing up, and by the time you notice it, it feels sudden but it actually wasn’t.
Yes, by the time you notice, you've already lost 10 users who never said a word. Silent churn starts way before the dashboard shows anything.
Most monitoring tools catch failure.
The more expensive problem is quiet drift.
That’s the layer most teams miss:
nothing breaks
nothing crashes
revenue just quietly stops moving
That’s much closer to operational blindness than observability.
And that distinction matters, because “monitoring” sounds crowded fast.
The stronger positioning here is not uptime.
It is catching silent business failure before it compounds.
NotiLens is clear enough, but it still feels slightly feature-shaped for what this becomes.
If this leans harder into operational anomaly / silent failure infrastructure, something like Davoq.com would likely carry more weight as the product matures.
Really appreciate this. "Operational blindness vs observability" is a sharper distinction - going to think about how to surface that more clearly on the site. On the name, NotiLens is staying - but the framing you're describing is closer to where the product is heading than "alerting" is.
That makes sense.
If NotiLens is staying, then the main thing is making sure the site does not collapse back into “alerting.”
Because alerting sounds like:
something happened, notify me
But what you’re describing is bigger:
something is drifting before the business notices
That’s a stronger and more expensive problem.
I’d make “operational blindness” the enemy, not downtime.
That gives NotiLens a much sharper job to own.
Good framing. Already updated the headline today - "Catch Silent Business Failures Before Your Users Do." Still evolving.
That headline is much stronger.
“Catch Silent Business Failures Before Your Users Do” immediately moves it away from generic alerting.
I’d keep pushing that direction.
The more NotiLens owns “silent failure” instead of “monitoring,” the easier it becomes to stand apart from the observability crowd.
That’s the wedge:
not uptime alerts
not dashboards
not more noise
business drift before anyone notices.
That's the direction. "Silent failure" as the category, not "monitoring." Appreciate you pushing on this through the thread.
That’s the right lane.
If “silent failure” becomes the category, the site has to keep reinforcing that everywhere.
NotiLens can work if the positioning carries enough weight.
But the real test is whether people remember you as:
“another monitoring tool”
or
“the thing that catches silent business failure.”
If the second phrase starts repeating back from users, you’ve got the wedge.
That's the test worth running. Going to start paying attention to how people describe NotiLens back to us - "another monitoring tool" vs "the thing that catches silent business failure." If the second phrase starts coming back unprompted, the positioning is working.
Stephen, one practical follow-up on the NotiLens positioning.
I remembered this thread because you actually acted on the “silent business failure” angle and added the user-repeat question into early calls.
That is exactly the stage where a focused positioning audit could be useful.
The risk now is not the headline only. It is whether the whole site, demo flow, category language, and name support the same wedge, or whether buyers still mentally file NotiLens under generic monitoring/alerting.
I can do a sharp naming and positioning audit around this: current name risk, category frame, homepage language, user-repeat test, and whether “silent failure” is strong enough to become the category you own.
Not a long consulting thing. Just a written decision memo you can use before more demos, users, and messaging updates build around the current frame.
I’m doing a few of these at $99 while refining the format.
If useful, connect here and I can give NotiLens a clear outside read:
https://www.linkedin.com/in/aryan-y-0163b0278/
Exactly.
That user-repeat test is the fastest way to know if the positioning is actually landing.
If people say “monitoring tool,” the category swallowed you.
If they say “silent failure,” you’ve created the wedge.
That’s the difference between being compared to every observability product and owning a specific pain.
I’d pressure-test it aggressively in demos and early calls:
“What would you call this if you had to explain it to another founder?”
Their answer will tell you if NotiLens is carrying the new frame or if the site is doing all the work.
That question is going into every early user conversation. Clean signal, no leading.