We Raised $25Million to Redefine Kubernetes Troubleshooting

In May of 2020, together with my co-founder-in-crime Itiel Shwartz, we founded Komodor with the goal of building the best developer experience for troubleshooting in Kubernetes systems.

Twelve months later, I’m excited to announce the most recent milestone in our journey – a $21Million Series A round led by Accel, joined by industry veterans such as Jason Warner, CTO of GitHub; Sri Viswanath, CTO of Atlassian; Danny Grander, Co-Founder of Snyk; and Tomer Levy, CEO of Logz.io. This comes on the heels of a $4Million Seed round from NFX Capital, Pitango and the OldSlip Group we raised just a year ago, in May 2020.

It’s been a wild ride so far and we are humbled by the great response to our vision from customers, investors and – most importantly – the Komodor team that chose to join us on this journey.

A Tool We Wished We Had

Like so many other dev tools we ourselves use and love, the idea of Komodor was also born out of our own necessity, inspired by the real-world pains we felt as developers.

I met Itiel 10 years ago at Tel Aviv University, where we were both majoring in Computer Science. It was a ‘friendship from the first pint’ and we quickly found ourselves spending days and nights brainstorming about possible business ideas while participating in every entrepreneurship program the university had to offer.

Fast forward a few years, our careers took us in different directions but we always continued to keep in touch and talked about making something of our own. Over time this took the shape of monthly walking meetings, most of which were spent talking about our work experiences. 

As the conversation went on, we noticed a pattern emerge. It became apparent that, whether working for a growing startup or at Google, we and our fellow devs were spending way too much time and emotional energy on troubleshooting.

Anyone who has ever been on-call can relate to this notion – the sinking feeling of a PagerDuty alert telling you that something has just gone wrong and signaling a race against time to get to the root cause.

That race, we knew, almost always started with the same question: “What changed?” Trying to find the answer would end up eating hours of time as you log in and out of multiple monitoring and observability tools, CI/CD, code repositories, and communication channels…

Back-and-forth and back again, looking for that needle in the (hay)stack. And that’s if you were lucky, because sometimes finding the answer would be simply impossible. 

It was also clear to us that these problems will only get worse, as the systems grow more complex, fueled by the rapid adoption of the modern highly complex and distributed microservice environments. 

From this realization the idea of Komodor was born, as we set out to build a tool that we ourselves wished for during those middle-of-the-night PagerDuty alerts – a tool that would make troubleshooting low-effort and worry-free by showing exactly who did what and when. 

K8s Needs Intuition-at-Scale

As luck would have it our ‘Eureka moment’ happened at the height of the COVID-19 pandemic. Not perfect timing for financial risk-taking,  but with a decade of pent-up energy we were not in the mood for slowing down. Things started to happen quickly. We quit our day jobs and within a few months raised a seed round, were joined by the first Komodorians, got an office (even though it didn’t see much use during the lockdowns), and started working on the beta. 

In the process of doing so, we engaged with 100+ organizations worldwide, several of whom would later become our first customers. From these conversations two things became apparent:

1. The task of troubleshooting often fell on the shoulders of the most experienced developers and DevOps, who had an almost intuitive understanding of the system’s inner workings. This understanding, however, couldn’t be easily taught to the rest of the team, especially in hyper-growth and high turnover dev organizations.  

2. Many of the organizations were in the process of moving to Kubernetes and this shift took away many of the tools normally used for troubleshooting and change intelligence, further extending the aforementioned expertise gap.

This in turn led us to the following conclusions:

1. We need to create a tool that would close the expertise gap and – for the lack of a better term – deliver troubleshooting intuition-at-scale.
   
2. Our platform needs to be laser-focused on K8s environments.

Back in 2020 focusing on Kubernetes still managed to raise a few eyebrows. A year later, however, we see our bet starting to pay off, with the rapid adoption of K8s technology at a pace we can’t help but compare to what we saw with Linux, back in the day.

Now, following a successful product launch and with some of the world’s largest dev organizations using Komodor on a daily basis, we already have our eyes on the next horizon.

We have a roadmap full of great features, and our heads are buzzing with WIP ideas that expand on the boundaries of our initial vision.

But while Komodor will continue to change and evolve, our core mission will remain the same: freeing developers to focus on what matters most – creativity and innovation.