100 GitHub Releases. Yet it's day one 😊

Here’s to the next 100. We’re just getting started!

💌 Hey there, it’s Elizabeth from SigNoz!

This newsletter is an honest attempt to talk about all things - observability, OpenTelemetry, open-source and the engineering in between! We at SigNoz are a bunch of observability fanatics obsessed with OpenTelemetry and open-source, and we reckon it’s important to share what we know. If this passes your vibe-check, we’d be pleased if you’d subscribe. We’ll make it worth your while.

This piece is written by Anushka, PMM at SigNoz, on account of completion of 100 releases at SigNoz.

Also, feel free to check out our blogs and docs here. Our GitHub is over here, and while you are at it, we’d appreciate it if you sent a star ⭐ our way. You’re also welcome to join the conversation in our growing Slack community for the latest news!

Cheers.

We just shipped our 100th GitHub release.

You would think a milestone like this would feel like an arrival, a moment to look back and say, “Yay, we made it.”

But when I sat down with the team to understand how they felt, everyone said some version of the same thing - “We are just getting started.”

To understand what it actually takes and feels like to ship 100 releases, I talked to a few of my teammates from different junctures of the product story.

This is their story. Welcome to our journey of 100 releases.

A quick side note on methodology: My highly scientific process for selecting interviewees involved grabbing anyone who wasn’t in a meeting at the eleventh hour. While their stories are amazing, they are just a few of the many that make up our 100-release journey. A huge thank you to the entire team!

The first hire

Ashu was the third person at SigNoz, joining the two founders in May 2021 as a Growth Manager. His job was to let more developers know that SigNoz existed and that it was OpenTelemetry native. When he joined, SigNoz had around 600-700 GitHub stars.

The problem was that nobody was paying attention yet. Our Slack community had crickets. But Ashu believed in the founders and their genuine care to improve the experience of fellow developers. This was his push to keep going.

He kept writing content on dev.to, publishing on Hacker News, and explaining how to implement OpenTelemetry in Java applications when OpenTelemetry itself was brand new.

This soon became a habit. It eventually built up and gave us numbers to chase.

We’d trend on GitHub occasionally, articles would go viral, and when people visited the repo, they’d see the value and star it. The momentum kept attracting people. Soon, contributors started trickling in. Later, customers became contributors too.

Today, SigNoz has 24,200+ stars on GitHub (as of 5th Nov, 2025).

The first backend engineer

While Ashu was getting the word out, Vishal joined us in November 2021 as our first backend engineer, starting on the traces module. For us, OpenTelemetry was never a mere technology choice; it was in our DNA from day one. We learned from the OpenTelemetry community, raised issues upstream, and helped debug.

Community was always core to what we were building.

As the product gained traction, users started asking for a SaaS version. They didn’t want the hassle of setting up and maintaining the open-source infrastructure. The team decided to launch SigNoz Cloud during a workation in Goa in December 2023, with the idea of just doing a one-week soft launch to test for issues and then rolling it back. In the first week, we got four signups. We never rolled it back.

Vishal remembers the chaos of that launch vividly. The team was at the beach when Nitya got a message about the sign-up flow being broken and him running back (literally) to the room to fix it. That workation launch, which they thought was just a pilot, became the real thing.

That’s when Vishal’s role shifted. He went from being a backend engineer to a product manager, spending his days on calls with customers, debugging issues, and doing manual setups. The work wasn’t glamorous. There were sleepless nights and pressure from large companies to prioritize their features.

But that messy, tedious work had to get done. Customers like Kiwi helped shape the product through their feedback and pull requests, pushing us to build for actual scale, not just theoretical scale.

Bringing logs to the product

When Nitya joined in April 2022, we had around 40-50 weekly active users. His first task was to bring logs into the product. We had traces and metrics, but logs were the missing piece.

Just a month after he joined, during a team workation in May 2022, a conversation over lunch set the tone for how we build. Pranay, CEO of SigNoz, asked Nitya what he was working on.

“Logs. Building out the schema,” Nitya said.

“How much data are you testing on?”

“One million.”

“No, no. Test it on one billion.”

Nitya spent the next week running schemas against a billion log lines, again and again. That ambition became our standard. When we released the first logs benchmark, it caught fire on Hacker News. The traffic exploded, and with it, more customers and more data.

But as customers grew, so did the complexity. Nitya manually migrated hundreds of customers to new schemas over six months. We couldn’t afford to lose their data or break their workflows.

What worked at 50 users didn’t work at 500. Every new customer taught us something, and every incident made us more careful.

The first frontend lead

We had a functional product, but it was far from pretty. That’s where Yunus came in, joining in August 2023 as our first frontend engineer.

Frontend engineers typically don’t gravitate toward dev tools, which are often built for SREs and backend folks. But Yunus wanted to build a culture where engineers think beyond their specific skillset.

His philosophy was simple: “You are not a frontend engineer or a backend engineer. You are a software engineer.” He wanted everyone to understand the ‘why’ before getting into the ‘how.’

This thinking was crucial.

When Yunus joined, we were moving fast, but we weren’t always thinking in systems. He focused on building processes to make our frontend more stable and predictable because people make mistakes, but good systems can prevent those mistakes from breaking things.

Joined at the 34th release

Vikrant joined as a frontend engineer in January 2024. The frontend wasn’t stable; fixing one thing often broke another. He felt disconnected from the full picture, but an opportunity came up that changed everything. The provisioning flow for new sign-ups was constantly breaking, and Vikrant had already expressed interest in learning backend.

So he made the shift. He had a one-month crash course, taking over ownership from Pandey. It was a ticking bomb. Either he figured it out, or the sign-up flow stayed broken.

And damn, he did figure it out.

Later, the community asked for something ambitious - loading traces with millions of spans. We didn’t want to build a makeshift solution. We wanted to solve it permanently. After two months of intense work, we could load a million spans on a single screen.

Then came the push for provisioning v1.0. Our deadline was the Tuesday platform retrospective at 6:30 PM. As the clock ticked, the call got pushed to 7:00, then 7:15, then 7:30. We finally deployed to production, tested it, and joined the call right after. The entire team stood (well, practically sat in front of their laptops) together until v1.0 was stable.

The next challenge was to improve our SQL database schemas. For three months, we had to break down our entire infrastructure and rebuild it. Every Wednesday noon, Vikrant, Pandey, and Nitya would send each other memes, about the known pattern - a release would go out, and by 12:30 PM, a bug would be reported. Every single time.

But as Vikrant puts it, “If you’re tired, do it tired.” And when you have the back of your team, it does get easy.

Building processes that scale

Pandey joined in February 2024, when SigNoz was just a bunch of people executing. There were no pods, no real structure. His first task was to stabilize data ingestion. Every other day, a customer complained they couldn’t ingest data. It was a race against time.

After stabilizing ingestion, he turned to a bigger question - What does it take to run a high-performing team?

He laid the foundation for the platform pod, starting with just him and Vikrant. They implemented sprints, retrospectives, and reporting - a process that ran for eight months with just the two of them before being adopted company wide.

Introducing structure wasn’t easy. It led to internal friction and disagreements on how things should be done.

But as Pandey notes, the culture being set today is what new people will embody. That’s how the baton gets passed.

Eight months in

Piyush joined in March 2025, and eight months later, he says it already “feels like forever” in the best way. At previous companies, the push was to ship features fast, any way possible. Here, he found the time and space to do it the right way the first time.

Working with Nitya on logs, he had to learn a new way of collaborating remotely. It took a few weeks to align on the thinking behind testing certain things, but over time, the context builds.

Now, Piyush is in the position Nitya was in when he first joined. He is responsible for making logs better and working on complex features like cloud integrations. He’s also exploring JSON logs, which he believes will boom fast and make many data pipelines redundant.

And well, his story connects everything. Someone is still at their Day 1, even on our 100th release.

Day 1, again

Every Wednesday, I look forward to the release. And it’s not just because I write the changelog. It’s become my favorite part of the week. As a marketer, I couldn’t ask for a better way to stay connected to what we’re actually building.

Yet here I am, writing a nostalgic story instead of a technical, feature-tracking blog. Because at the end of the day, there are humans building these sophisticated features, and their stories are worth hearing. at least sometimes, if not often.

The Day 1 feeling isn’t restricted to engineering. A few days ago, we launched our first-ever mascot. We ran our first integrated campaign. Every one of these feels like a beginning.

It’s Ashu pushing through the crickets. Vishal doing the messy, unglamorous work. Nitya testing for a billion when a million seemed like enough. Yunus building systems, Vikrant doing it tired, and Pandey introducing structure when velocity felt more important.

These stories are limited to a few, but they echo the team’s sentiment at large.

Here’s to the next 100. We’re just getting started!

---

This spirit extends beyond our internal team. Our community has been with us every step of the way, which is why this past July, we were thrilled to launch the SigNoz Community Advocate Program. It’s our way of recognizing the passionate developers who help others succeed with observability.

Shout-out to our inaugural advocates for their incredible contributions: Mathew Gilham, Matti De Grauwe, Kieran Pilkington, Gil Felot and Nicolas Lamirault.

And in a moment of perfect serendipity, just as I was about to create the PR for this post, we welcomed our 500th paid customer.

---