jjtang1

It's always a bit jarring when a tool you've relied on announces its sunset. Opsgenie has been a staple for many teams, and transitions like this can stir up a mix of nostalgia and uncertainty.

At Rootly, we've seen firsthand how integral these tools become to daily operations. They're not just software; they're part of the team's rhythm and culture. When changes happen, it's not just about migrating data—it's about adapting workflows and ensuring continuity for the people behind the screens.

We're committed to supporting teams through such transitions, aiming to make the process as smooth as possible. Our focus has always been on building solutions that prioritize the human element in incident management.

To those navigating this change, know that you're not alone. The community is here, sharing insights and offering support. If there's anything we at Rootly can do to assist, even if it's just sharing best practices or lessons learned, don't hesitate to reach out.

Tbh this took us about a day to build and well worth it. Makes on-call lives so much easier. Not sure why they don't yet https://rootly.com/changelog/sync-on-call-schedules-with-sla.... Sorry to be promotional.

Def worth taking a look at Rootly On-Call, we've helped everyone from Rivian to Brex migrate over from PagerDuty :)

JJ here, obviously bias as I am the founder of Rootly.com that's building in this space.

We are a modern AI-native on-call and incident management platform here at Rootly.com. We are helping fast-growing companies like from Replit, Figma, NVIDIA, and 100s of others respond faster.

Some of the biggest frustrations with legacy providers like PagerDuty (who I have a lot of respect for in pioneering on-call) is their lack of innovation (only a phone call) and how expensive it is.

Some fan favourites include request coverage for overrides, automatic adjustments based on PTO and holidays, native Slack/Teams collaboration (not just paging), native shadow rotations, syncing with Slack user groups, a beautiful UI and mobile app, and an all-in-one platform for status pages, workflows, communications, retrospectives, and metrics.

If you're a small team Rootly has a pretty discounted version for startups. Here is a full comparison if you're interested: https://rootly.com/comparisons/pagerduty-vs-rootly-on-call

Where you host is underrated. When I started building on-call for Rootly the first thing we did was build a multi-cloud setup (AWS and GCP) for honestly pretty overkill reliability. Don’t regret it one bit.

Happy to give them Rootly as a backup ;)

>Most of the software I wrote requires mostly no interference or fix-ups, unless of course the requirements have changed

Bug-free software is great, but changing requirements are precisely the reason on-call needs to exist.

Even if you have a whole team of engineers who write bug-free software like this guy, you'll still have failures. Because the world is constantly slipping out from under your assumptions.

Customers never stop changing their usage patterns. They add load at different rates, come up with unexpected requests of all shapes and sizes, and invent new use cases that fly in the face of the original project requirements.

Even if you have created a software system with no bugs that perfectly meets both the functional and non-functional requirements of the project, changes in the state of the world vis a vis customer behavior will come along and change what counts as a bug. If your system has a blanket 60-second database query timeout, and everything's working fine, then there's no bug. But as soon as a new API usage pattern causes certain queries to run on average 10 times longer than before, now you have connection starvation and an urgent bug to fix.

I'm not saying that "timely maintenance and improvement" and "a culture of perpetual ownership" won't have positive effects on reliability. But it's unrealistic that any amount of responsible, careful software development will fully eliminate the occurrence of sudden and unexpected failures. Human on-call, as uncomfortable as it is, will remain a requirement as long as reliability is taken seriously.

FWIW my perspective is that of someone that runs an on-call/incident management platform (Rootly).

There are certainly more alternatives than ever. I am certainly team "hosting your own on-call is a terrible idea".

Standalone tools like Rootly (where I work) but also likely every observability company in the next couple of years will follow what Datadog has done.

You’re too kind :)

Ahaha the final boss.

Who alerts you when your own alerting system is down?

You profile is pretty interesting. Lmk if you want to come on the pod!

Cool! Mention JJ in the demo booking and I’m happy to personally join :)

That’s not good. On it! Thanks for catching.

Oof. On it!

That is def one way to evaluate velocity.

Appreciate the love sir! Canva and RevenueCat are still one of my fav teams to work with!

Not trying to dunk on my competition but that is one thing that always surprised me too. Speed to deliver/innovate. I see large corporations all the time like even Slack (Agent marketplace), AWS (Bedrock), deliver at a high clip. PD truly had the opportunity to be a Datadog sized company given the brand name. Now it's a reputation impossible to shake.

There are some pretty low hanging fruit stuff that would make the PD experience palatable (e.g. ability to page teams not just services, allow for partial overrides). These things for us were <1 week projects.

I do think PD is trying to rectify it by acquiring Jeli, giving it away for free in their new pricing plan, etc. Def feeling the squeeze a bit if I had to guess.

Ah yes. Terraform is super popular for us (almost 1m downloads). We also built a pretty cool "Terraformer" tool that lets you create workflows in UI and translate that to .tf easily.

We take extensibility pretty seriously. Outside the basics, we just released our own agent ready API (https://rootly.com/blog/introducing-rootlys-api-ai-agent-fir...), MCP, docs are now LLM ready (https://docs.rootly.com/llms-full.txt).