DrDroid at KubeCon + CloudNativeCon India 2026

Two days on the show floor at KubeCon India talking Kubernetes debugging, alert noise, and what engineering teams actually want automated in production.

DrDroid joined KubeCon + CloudNativeCon India 2026 at the Jio World Convention Centre in Mumbai, one of the largest gatherings of Kubernetes, cloud-native, DevOps and platform engineering professionals in the region.

We came to talk about the gap every Kubernetes team knows well: the cluster emits every signal you could ask for, and none of it helps at 2am when you have four minutes and forty dashboards.

Meet the DrDroid team

Our engineers were on the floor across both days to answer questions, dig into specific failure modes, and swap stories about the incidents that took far longer than they should have.

What we demoed

Rather than a canned walkthrough, we ran live investigations against the failure modes people brought to the booth.

• CrashLoopBackOff traced to the memory spike that caused it, with no runbook involved
• OOM kills explained in terms of what changed, not just which pod died
• Alert storms collapsed into a single issue with a single owner
• Cross-service latency regressions correlated across traces and logs

What DrDroid does

DrDroid is an AI SRE agent for infrastructure teams. It crawls your telemetry to build a knowledge graph of your stack, investigates alerts as they fire, and gives on-call engineers a root cause instead of a starting point.

AI investigations

Every alert is investigated on arrival, with the reasoning shown so engineers can check the work.

Alert grouping

One root cause becomes one issue, so an alert storm stops paging three teams at once.

Self-learning agent

The agent improves on your systems specifically as it works through more of your incidents.

80+ integrations

Kubernetes, Grafana, AWS, Sentry and the rest of the stack, connected read-only.

Runs in your VPC

Self-hosted or on-prem with air-gapped support, SOC 2 Type II certified.

What we took away from Mumbai

Two days of conversations landed on one point: the hard part of Kubernetes debugging is rarely finding the data. It is knowing which signal matters for this alert, right now, and that is exactly the judgment teams want help with.

Thanks to everyone who stopped by. If we talked at the booth and you want to pick it back up, the team is around.