Error trackers report what throws. The failures that cost the most throw nothing: a dead button, an overlay swallowing clicks, or a page that got slower after a Tuesday deploy. Nobody files a ticket, they just leave. HeronSignal catches those and ranks problems by sessions lost, not error count. Then it closes the loop. 40 read tools over MCP, so Claude/Cursor read your production directly. HeronAgent takes the diagnosis, writes the fix in a test-gated sandbox, and opens a draft PR for approval.
No reviews yetBe the first to leave a review for HeronSignal
Maker
📌
Hi Product Hunt 👋
I built HeronSignal after losing four days to a checkout button.
A deploy broke it for Safari users. Nothing errored. Sentry was clean,
uptime was green, sales were down 11% for the week, and we read it as a
slow week. We found it on Friday.
That bug threw no exception and failed no request. From the software's
point of view nothing happened. From the customer's, the product was
broken. I don't think that's a bug in Sentry. It's a category error
tracking structurally cannot see.
So HeronSignal watches for the shape the behaviour makes instead. The same
control hit three times in a second. A click where nothing a person could
perceive changed within three seconds. A page drifting from its own
baseline after a named release. When it catches one it keeps those few
seconds of session, so you can watch what they actually saw.
Two things changed how I thought about it while building:
1. Ranking by count is worse than useless. An error firing 4,000 times a
day where every session survives is cosmetic. One firing 30 times that
abandons 26 of them is costing real money. So we rank by what happened
to the session afterwards, not by volume. Getting that right took a
subtle fix: measure from the session's FIRST occurrence, not its last,
or any error that repeats looks like the thing that killed the session.
2. Your AI coding agent can read your repo but not your production, so it
writes fixes blind. That turned out to be the real gap. We exposed
everything over MCP (read tools), and separately built HeronAgent,
which takes a diagnosis, makes the change in a sandbox, runs your
tests, and only then opens a draft PR. Every PR explains itself under
four headings: why this change, what it improves, alternatives
considered, and how to verify. Always a draft. A human reviews it.
Two things I'd genuinely like your view on:
- Is "the failures that don't throw" a real category to you, or does it
sound like marketing for something your stack already covers?
- If you've given an agent access to production data, what did you
actually trust it to see?
Free scan needs no signup and no traffic: heronsignal.com/scan. Point it
at your own site and tell me if it's wrong.
I'll be here all day.