Launching today
Hyperprobe
Lets your AI agents debug production without redeploying
376 followers
Lets your AI agents debug production without redeploying
376 followers
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.
One Shot , drop 2 birds - Sentry & Datadog 😉
@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?
Hyperprobe
@suyash_kr yes we cover Memory OOM and CPU spikes
Mailwarm
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.
Hyperprobe
@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! 🙌
Dial
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?
Hyperprobe
@galdayan we redact common sensitive product data patterns within the sdk itself.
users can add more data patterns or key patterns to customize this
Dial
@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?
Hyperprobe
@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
Giving Claude Code/Cursor live runtime context instead of having it blindly guess from missing logs is a smart move. Congrats Hyperprobe team!