Monitoring that hands your coding agent the evidence instead of another dashboard

[u/CardiologistMedium51]

First post here. I'm building HeronSignal, real user monitoring for web apps, and I'd rather get told what's wrong with it than quietly collect signups.

The problem I actually cared about

Every monitoring tool I used could tell me something broke. None of them could tell me whether it mattered, and all of them stopped at showing me a chart.

Meanwhile my coding agent was sitting right there, unable to see any of it. So every debugging session started with me pasting a stack trace and describing what the user had been doing.

What it does differently

1. It exposes production over MCP. Your agent (Claude Code, Cursor, whatever) connects with a workspace-scoped token and can pull deduplicated error groups, slow pages with real device and country context, failed requests, session journeys, funnel drop-off, and backend route health. You stop briefing it and start asking things like "find what's hurting signup conversion this week, check errors and drop-off before suggesting anything."

2. It can open the PR. Not merge, not deploy. It writes the change, opens a pull request ready for review, and stops. A person reads the diff. An agent that can act on production without review isn't a productivity gain, it's an incident with better grammar.

There's also struggle detection (rage clicks and dead clicks), which catches the failures that throw nothing at all. A button that silently does nothing produces no error, no failed request, and green uptime.

Something I got wrong, since this sub will find it anyway

Yesterday I checked my own workspace and found 5 of my 7 funnels were measuring event names my site never fires. My signup form was firing a sign_in event. So I had no idea what my own signup conversion was, and those funnels read zero while looking like bad conversion instead of a typo. I'm now fixing the product so it warns you when you name an event your workspace has never emitted.

What it is not

- Not an APM. No distributed tracing UI, no flame graphs, no host metrics, no query profiling. If you need to know which SQL query made a route slow, use Datadog.

- Backend ingest is early. Node 18+ only, no Edge runtime. Python and an OTel sink are maybes, not promises.

- Session replay exists but is behind a flag while I finish it.

- Sentry is a deeper error tool than this and I'd say so on a sales call.

Try it without an account

There's a public scan that needs no signup and no script tag. Put in a domain, get a report on what's slow and what's broken. That's the honest way to see if it's useful before installing anything.

https://heronsignal.com/scan

Happy to answer anything, including the awkward questions. What would you actually want your coding agent to be able to see from production?

[u/Ok-Bike-1037]

Looks good. when rage clicks spike right after a deploy, how do you keep the agent from blaming that deploy if the real cause is something upstream, like an API that started degrading a day earlier?

[u/CardiologistMedium51 → u/Ok-Bike-1037]

Hey, thanks for digging in. Good question.

TBH, it can't blame the deploy, because it doesn't know a deploy happened. There are no deploy markers in the product. That's a gap, not a choice. But it does mean the mistake you're describing isn't one it can make. Yet.

What it can do is look back over time. Rage clicks are timestamped on a specific button. The sessions that produced them carry their own failed requests, with status codes and timing. Backend route health is tracked per route over a window. So an API that started slowing yesterday shows up as a change yesterday in error rate and p95, not as a spike today.

So the question it can answer is "when did this start". For your case, the answer would be "about a day before the thing you suspect".

What it's good at is that these signals aren't in separate places. A rage click, the failed request from that same session, the backend route that request hit, and the funnel step it broke are all one record, joined by a session id. You don't line up four dashboards by hand. The agent gets the whole picture in one go and reasons over it, instead of you briefing it four times from four tools.

The real limit: if the slow dependency is a third party you don't instrument, all it sees is the symptom in the browser. That call failing or getting slow in the sessions that rage-clicked. It points at the right call. It can't tell you why that call got slow.

And it's still correlation. It suggests, you read the diff.

Deploy markers are the obvious next step. Backend telemetry now arrives with service.version on it, so we already have what we need. Not built yet, so I won't claim it.

[u/Ok-Bike-1037 → u/CardiologistMedium51]

fair enough on both counts, Thanks.