HyperProbe is how backend teams debug production issues they can't reproduce locally. Instead of adding a log line and waiting on a deploy, we let Claude Code, Codex, or Cursor drop read-only probes into a running service and capture the variable state that was never recorded. From there your agent debugs like it has a local repro, closing the bug in one sitting.
Payment Required
Launch Team / Built With
Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
@shailendra_singh_ht . I zunderstood that this can be helpful for debugging running logic issues, can this be used to diagnose performance bottlenecks or memory leaks as well?
@suyash_kr yes we cover Memory OOM and CPU spikes
Excellent!
@yahia_bakour3 thanks!
Congrats on today's launch!!
Read only isn't the same as safe here. The probe still lifts live variable values, so the first question from any security team is what happens when an agent probes the frame holding a card number or a session token, and whether that value ends up in your storage. Zero overhead is doing a lot of work in that sentence too, I'd put a p99 next to it. The 9.5 minutes is the number that actually sells this.
@asadmalik901 PII redaction in-process handles this. Our PII bank auto identifies this or you cans set field level redaction yourself
Huge congrats on the launch, team!
Debugging runtime production issues when using coding agents has always felt like the biggest bottleneck. Giving agents dynamic, real variable state right from the IDE instead of digging through logs and constantly redeploying is an absolute game-changer.
Excited to see how HyperProbe transforms AI-assisted workflows. Wishing you guys massive success today! 🙌
Interesting approach, but I'd want to understand the guardrails before letting an agent do this on its own. "Read-only" still means the agent is deciding on its own, at 2am, which running production service to attach a probe to and what to inspect. Is there any human approval step in that path, or an audit log of every probe that gets dropped, or is the trust boundary basically "we trust the agent's judgment on production systems" out of the box?
@galdayan we redact common sensitive product data patterns within the sdk itself.
users can add more data patterns or key patterns to customize this
@shailendra_singh_ht thanks, that answers the data privacy side but I was actually asking something slightly different - not what data the probe can see, but who decides where the probe goes. is there a human approval step before an agent attaches a probe to a specific production service, or an audit log of every probe placement, or is that entirely up to the agent's own judgment in the moment?
@galdayan both. Humans can place probes from the IDE or let the agents do this for them. The agent loop is faster and just needs the human to explain the problem in plain english. We have audit logs of every probe and our enterprise plan carries an approval gate for every probe placed which works like a maker-checker mechanism. Probes have TTL, expire automatically after a certain number of hits and ca be set conditionally on user types or specific users
@shailendra_singh_ht that's the actual answer, thanks for clarifying - approval gate plus TTL-based auto expiry plus conditional scoping by user type is a solid model. good luck with the launch
Giving Claude Code/Cursor live runtime context instead of having it blindly guess from missing logs is a smart move. Congrats Hyperprobe team!