DEV Community: Mads Quist

Why We Built Live Call Routing the Lean Way

Mads Quist — Thu, 25 Jun 2026 10:29:00 +0000

When email is not enough, you need a human on the phone. Live Call Routing should not require a sales cycle or telephony markup. Here is how All Quiet built it the lean way.

Why We Built Live Call Routing the Lean Way

Most on-call setups run on automated alerts, and that covers the majority of pages. It stops being enough when a production database goes down at 3:00 AM, or when a high-priority customer is in a full outage. A support email or chat message does not always cut it. Sometimes you need a human on the phone.

If you have looked at Live Call Routing in other incident tools, voice often sits behind enterprise pricing or a reseller markup. We wanted the opposite: a straight path from caller to on-call engineer, without a sales call in the middle.

The All Quiet approach to voice

No enterprise gating: Live Call Routing is available on our Pro plan. No "call for quote" required.
Bring Your Own Provider (BYOP): Connect your existing Twilio account via API. You keep your numbers and your provider relationship.
Zero markup: You pay Twilio directly. We do not take a cut or markup your telephony rates.
Dev-first config: Manage your Interactive Voice Response (IVR) via our UI or via Terraform for infrastructure-as-code teams.

The "contact sales for pricing" wall

Setting up a live hotline or an IVR menu with some VC-backed competitors usually ends the same way: "Contact Sales for Enterprise Pricing."

For those vendors, voice routing is a lever to push smaller teams into annual contracts and, often, to resell telephony at a margin. You end up paying a middleman for infrastructure you could run yourself.

We are revenue-funded, not growth-at-all-costs. If you need a duty phonefor your infrastructure, you should not need a procurement cycle to get one.

Why we chose Bring Your Own Provider (BYOP)

When we designed call routing, we had two options:

Resell phone numbers and charge a premium on every minute.
Build routing logic that plugs into the VoIP stack you already run.

We chose the second. All Quiet integrates with Twilio so you wire in your API keys, map your virtual on-call numbers, and keep paying your provider's rates.

Zero telephony markup: You pay Twilio directly. We handle inbound call routing and on-call logic; we do not touch your minute billing.
Data stays with you: Call recordings and provider-side logs remain in your Twilio account. We run the routing and incident creation so the right engineer gets the ring, without copying your voice data into a separate silo.

SRE-first design: UI-friendly, Terraform-ready

Enterprise phone systems are built for call centers. Menus go deep, labels use telecom jargon, and the admin UI assumes a dedicated phone team. We built for DevOps and SRE workflows instead.

1. IVRs should not require a certification

Our visual builder lets you map Press 1 to Overnight Squad in a few clicks. The point is to set up a bridge during a mid-level incident without opening a vendor manual. Less cognitive load when the pager is already loud.

2. Infrastructure as Code (yes, even for your phone tree)

A good UI helps for quick changes. Most teams still want version control, review, and repeatability for anything that affects production response paths.

All Quiet is API-first and Terraform-ready. You can manage Live Call Routing the same way you manage AWS or GCP resources. If you already treat on-call configuration as code, your phone tree can follow the same workflow, including escalation paths when the first responder does not answer.

Available for everyone, not just enterprise

We did not put Live Call Routing behind an Enterprise tier. It ships on Pro because a five-person startup handling a customer outage deserves the same voice path as a larger org.

All Quiet is a lean incident platform for the people who actually run the systems. Without a massive sales org to feed, we can ship features that solve on-call problems instead of features that inflate contract size.

Want to wire up your first dev-friendly hotline? Start a free trial and connect your Twilio integration in a few minutes.

On-Call is the daily business; Incident Management is a Philosophy

Mads Quist — Thu, 18 Jun 2026 10:27:00 +0000

If Your On-Call Strategy is Just "Make it Louder," We Need to Talk.

What exactly is a "better pager"? Maybe it has a cleaner UI, a louder alert, a fancier dashboard? Or is it just the industry's equivalent to replacing a warning light with a brighter bulb and calling it innovation?

The truth is that the pager was never the problem when it comes to incident management software. Making it look better won't magically erase the chaos, and it certainly won't invite clarity. A coherent and structured system is the real golden goose; a philosophy that teams can follow, a new way of working that replaces the panic-inducing surprises with manageable, predictable events.

In short: on-call is the "who," but incident management is the "how."

On-call is straightforward: it's the schedule, the rotation, the person behind the phone when the alert screams that something's wrong. It's the human on the other end of the chaos whose dinner goes cold while they put out the fire.

Incident management is everything that happens around that moment of panic: the structure that determines what's escalated, how information flows between systems, who communicates with whom and how the team learns from what happened. It's the difference between "someone's been alerted" and "we know exactly how to respond to this."

A healthy incident management philosophy answers questions like:

What incidents are important enough to wake someone up?
How do we make sure the right person gets the right alert?
What information should the alert include?
How do we communicate internally and externally?
How do we learn from these events and prevent them in the future?

If your system isn't answering these questions, then your pager is probably doing all the work... and that's usually when burnout happens.

Why does philosophy matter for SRE or DevOps leaders?

Here's something many leaders don't often say out loud:

Psychological safety is operational infrastructure, not an engineering luxury.

Teams need a clear incident management philosophy to follow, otherwise the emotional and cognitive load of engineers skyrockets. It usually manifests in one of two predictable (and equally damaging) ways.

Scenario A: Alert fatigue

Over half of large companies get 1000+ security alerts a day. A day. And 93% of them can't even be addressed on the same day.

If your engineers are constantly bombarded with problems they physically can't solve, they'll either tune out or stop distinguishing between important and unimportant signals. Or, worst of all, they'll become completely numb to the noise (hello, burnout).

The human brain wasn't meant to be crammed with as much information as it is today. No one can meaningfully respond to hundreds, let alone thousands, of alerts in an 8-hour workday, and they can't be expected to either. It'll only lead to exhausted engineers, missed incidents and a team that slowly loses trust in the alerting system (and their leaders).

Engineers aren't falling asleep on the job because they're bored, but because they're exhausted. They can't be asked to do the impossible.

Scenario B: The needle-in-a-haystack

Almost the opposite of scenario A, yet just as harmful, involves engineers trying to triage everything, all at once. They comb through every alert, every log line, every single anomaly and cross their tired fingers that they'll eventually catch the one that matters.

But all this does is create a sense of failure. It perpetuates the idea that no matter how hard they work, they'll never keep up. The sheer volume of alerts means they're always behind, trying to stay afloat in a sea of noise without a life raft.

And you don't have to be a genius to know where that ends up: they drown in the waves of problems they can't solve. It eats away at their confidence, motivation and psychological safety, making them feel incapable when, really, the system itself is unmanageable.

The real issue

When all's said and done, the real problem is the system, not the people. And system problems need system thinking. Without a set of guiding principles, teams default to survival mode rather than logic. Survival mode isn't a long-term strategy and it's the quickest road to burnout, high turnover and operational chaos.

"I need an alert" vs "I need a system"

The real deal: the mindset shift that separates resilient engineering organizations from those that are constantly fighting fires.

Surface-level fix

"I need an alert" is the pager-centric mindset. It's the "solve the immediate symptom and deal with the outcome later" mentality that fails to address the underlying complexity of incident response. A simple pager can't solve:

Prioritization: which issues matter most and why?
Routing: who's best equipped to handle this?
Context: what information does the responder need?
Communication: who needs to be informed and why?
Learning: what did we discover and how do we prevent it from happening again?
Prevention: how do we strengthen the system long-term?

Relying on alerts alone is like seeing a dashboard light on your car and thinking, "Well, time to buy a new engine." Alerts tell you something happened, but not what, why or how to stop it from happening again.

Structural fix

A real incident management system allows teams to respond effectively and sustainably by creating:

Focus: engineers see only what really matters.
Continuity: incidents don't disappear into Slack threads.
Predictability: everyone knows the drill and understands the playbook.
Accountability: someone's responsible for handling a task without blame.
Learning loops: incidents become learning opportunities instead of recurring nightmares.

This is that golden moment where incident management stops being a "tool" and becomes a philosophy. It can shape culture, reduce stress and improve reliability (and your engineers will thank you for it).

How All Quiet helps teams build chaos-free philosophies

Tools don't create philosophies, but they can reinforce them. All Quiet is built to support the kind of system modern engineering teams need; not by adding more noise, but by creating clarity.

Noise reduction that actually works

Not every alert needs human attention; some resolve themselves, while others need three engineers sweating over them with an Olympic swimming pool of cappuccinos. Some alerts are even duplicates, and some simply aren't important at all. But how do you know which one is which when they all look the same at first glance?

All Quiet knows. It helps teams filter out the noise so engineers can focus on the important stuff. It's not just reducing the number of alerts, but allowing engineers to put their trust in the alerting system itself. If the engineer knows the alert is meaningful, they respond faster and more confidently.

Built-in learning

Every incident is an opportunity to strengthen the system. All Quiet makes it easy to capture:

What happened
Why it happened
How to prevent it in the future.

Rather than constant stress cycles, incidents can be embedded in the organization's memory. They build a culture of continuous improvement where incidents can be fully understood, which ultimately leads to easy prevention for the future.

Routing based on actual knowledge

When a real incident hits, All Quiet uses the alert's attributes, like the service, the component, the impact, to route it to the right person. So Susan in accounting won't suddenly be slapped with 31 alerts she has no idea what to do with; the right person will know exactly what to do. This means:

No more "everything goes to whoever's on-call"
No more guessing who should handle what
No more accidental routes (sorry, Susan)
No more unnecessary escalations.

The incident finds its home quickly, with the person who's fully equipped to fix it the fastest. And shortens the resolution time in the process.

Communication that builds trust

Clear communication is a must-have for any business, but it's one of the most overlooked parts of incident management. With All Quiet, teams communicate internally, so everyone knows who's handling what, and externally through status pages and outbound updates.

Believe it or not, transparent communication increases trust. In fact, employees in high-trust workplaces experience 74% less stress and 40% less burnout.

And customers love it too—they expect competence, not perfection. They want to know that when something breaks, the right person will pick it up and fix it rather than handing it off to someone else.

The result: a team that doesn't fear the pager

At the end of the day, incident management isn't about louder alerts and shinier dashboards with all the bells and whistles. It's not even about who can stay awake the longest (cough DevOps engineers cough); it's about building a system that protects your people as much as your platform.

Teams with clarity, structure and a shared philosophy feel like they can weather any storm, no matter how unpredictable. That way, engineers know what to do, leaders know what to expect and customers know they're in good hands.

The end goal isn't less incidents, but less chaotic incidents; not perfect uptime, but predictable and sustainable responses; not heroics, but healthy and confident teams who trust the system they're working with. Strong philosophies mean the pager is just another tool rather than the entire strategy. The system supports the human behind it, on-call stops being something to fear and starts being something your team handles calmly and proudly.

If your current approach feels like you're stranded on a desert island in the middle of the Atlantic, don't blame your engineers. Your system is asking too much and giving too little, but the right one (with the right tools to support it) can build an environment where incidents are manageable and your team can finally breathe again.

A better pager won't get you there. A better system will. Make the choice easy and talk to us today.

Infrastructure as Code (IaC) is Not an Add-On

Mads Quist — Tue, 16 Jun 2026 10:17:00 +0000

When rotations drift and no one remembers who changed what, the pager still works but trust erodes. Incident management belongs in Git, reviewed and applied like the rest of your infrastructure.

If It's Not in Git, It Doesn't Exist: Why IaC Isn't An Add-On for Incident Management Platforms

Engineering teams are no stranger to the unwanted moment of opening a config page, tilting their heads and saying, "Huh... that's not what I expected."

Is it a rotation that doesn't match the team doc? An integration that looks a bit different from the one in staging? Maybe it's a schedule that was definitely updated last quarter but now looks a bit scant.

Nothing's broken, no one's being paged unnecessarily, the incident management software is doing exactly what it's supposed to, but something's out of sync and no one can remember when or why it changed.

Since these small friction points don't cause outages, they're more likely to go unseen. But that's exactly where the problems start. They accumulate. They're a sign that the configuration has slowly drifted away from whatever the team thought the source of truth was; which brings us to Infrastructure as Code.

What is Infrastructure as Code (IaC)?

IaC is the idea that your infrastructure, and all the little operational details around it, should be defined in code, stored in Git, reviewed like every other change and applied consistently. It replaces:

"I swear I updated that"
"Who clicked this?"
"Why does staging look different from prod?"
"Wait, when did this change?"

...with a single, reliable answer: Git history.

And it's nothing fancy either. It's simply a better way to align humans and systems. It's discipline; it's the decision to treat operational configuration with the same rigor as application code. That means:

No undocumented UI changes
No relying on memory
No tribal knowledge
No "just tweak it real quick" edits.

And as teams grow (and responsibilities spread across platform, SRE, DevOps and product engineering), a shared, reviewable, auditable source of truth becomes non-negotiable.

Interestingly, IaC adoption often starts with infrastructure provisioning. Operational workflows like incident management follow later as teams mature, even though things like schedules, rotations, integrations and everything that keeps a team responsive, benefit from IaC just as much as VPSs, clusters or load balancers.

That's where tools like All Quiet (and its Terraform provider) come in. They give you a clean, modern incident management experience, all while allowing you to manage it the same way you manage the rest of your infrastructure (which is predictably, I hope).

The real problem with manual rotations

We all love incident management tools. They keep teams responsive, informed, and most importantly, sane. But when you rely on manual updates for scheduling, rotations and integrations, you introduce some classic DevOps villains.

Configuration drift

Silent and sneaky, it waits until your head hits the pillow to show itself. It slowly erodes your confidence in what's deployed and is the main reason staging and production sometimes feel like distant cousins instead of twins.

Human error

Not because engineers are careless, they're just busy (sometimes too busy). Manual updates rely on memory, timing and attention, all of which are finite resources and ever-more dwindling during midnight crises.

Zero visibility

"Who changed this? When? Why? How? Oh, it was me... right." If the answer requires Slack thread excavations, you've already lost.

Multi-team complexity

The more teams you have, the more likely someone will accidentally summon chaos. Especially when each team has slightly different processes, naming conventions or expectations.

Manual configuration isn't bad, it's just not scalable. And incident management is one of the last places you want surprises.

Terraform 101 (explained like you're a smart engineer who just wants the short version)

Now we're getting to the good stuff.

To keep things simple, Terraform is basically Git for your infrastructure's memory.

You write down how you want your world to look, let's say your schedules, your integrations and your escalation paths, and Terraform waves a magic wand and makes it real. Sounds like pie in the sky but it's actually much simpler than it sounds. The workflow looks like this:

Write the configuration: Declare what you want, not how you want it.
Plan the change: Terraform shows you exactly what will happen before anything happens.
Review the diff: Humans get to sanity-check the machine.
Apply with confidence: Terraform updates the real world to match your code.
Audit forever: Every change lives in Git. Forever.

Easy peasy.

And thanks to the All Quiet Terraform provider, the same lifecycle applies to your incident management setup. Suddenly your on-call world becomes code, versioned, documented, safe from Friday-afternoon edits.

If you want Terraform explained in a more philosophical, AI-generated way, the provider is surprisingly patient at explaining that too (I say with experience).

All Quiet + Terraform: A match made in DevOps heaven

Here's where it gets a bit more fun (bear with me, now).

Rather than treating IaC like a bolt-on, All Quiet's Terraform provider treats it like royalty. Everything you configure, from schedules to rotations and everything in between, can live in Git. It can go through pull requests and follow the same DevOps lifecycle your infrastructure already does (cheers in DevOp).

A few reasons the dynamic duo works so well:

No more mystery changes

Every update has a commit, a diff and a human attached. In other words, accountability becomes second-nature.

Centralized control

Terraform enforces who can create integrations and schedules. You don't need to give every engineer admin access to your incident management tool.

Consistency across teams

Everyone follows the same pattern, naming conventions and lifecycle, whether across two teams or 20.

Predictability

Terraform doesn't forget to update the rota because it was hungry and the rugby starts at 7 p.m. (neither do your engineers... ideally).

All Quiet gives you a clean, modern incident management experience, while Terraform keeps that experience consistent, scalable and drift-free.

What IaC unlocks for incident management

IaC is much more than just a nice idea. It's a force multiplier that your future self (and on-call engineers) will thank you for. Here's why.

Predictability

Git always knows what's deployed, which means you always know too.

Auditability

No more detective work or moments of temporary amnesia when every change is fully documented.

Reproducibility

Need a new team? A new rotation? Maybe a new integration? Copy, paste, apply. Done.

Governance without bureaucracy

Centralized control without slowing teams down or creating bottlenecks.

Less cognitive load

Your team doesn't have to remember how to "do the thing." They just write the code.

An example of managing on-call via code

Here's a little taste of what managing on-call with Terraform might look like:

resource "allquiet_team" "my_team" {
  display_name = "My Team"
  time_zone_id = "America/Los_Angeles"
  incident_engagement_report_settings = {
    day_of_week = "mon"
    time        = "09:00"
  }
  labels = ["Product", "Services", "Operations"]
}

resource "allquiet_schedule" "backend_team" {
  name = "Backend Team On-Call"
  rotation {
    users  = ["alice", "bob", "charlie"]
    length = "1w"
  }
}

Readable, reviewable, reproducible. And most importantly: no surprises.

The cultural shift to IaC as a first-class citizen

The nuance that most IaC articles miss is that IaC isn't just tooling, but a mindset.

Most organizations prioritize coding infrastructure, CI/CD and observability long before incident management, even though it's one of the most critical and high-impact systems you have. Incident management deserves the same lifecycle and version control as every other system; maybe even more.

Think of it this way: if you can spin up a Kubernetes cluster via Terraform but can't page the right person in the middle of the night, is it really worth it?

The future is declarative (and much less painful)

Incident management isn't chaotic by nature; on the contrary, it's meant to reduce chaos by telling you what's not calm. It only becomes chaotic when the underlying configuration drifts, mutates or hides in a UI somewhere.

By treating incident management like code (especially with a provider built for the DevOps lifecycle), you calm the chaos. You invite consistency and visibility, which all lead to more control.

And with All Quiet + Terraform, your setup respects your workflow, your teams and your sleep schedule. Your future on-call engineers will never know the panic-inducing chaos you saved them from. Keep those futures safe and talk to us today.

Top Opsgenie Alternatives and Migration Targets: How to Transition in 2026

Mads Quist — Tue, 09 Jun 2026 10:24:00 +0000

Atlassian recently announced the official end-of-life for Opsgenie. Organizations must now prepare for a full service shutdown on April 5, 2027. To maintain reliable on-call schedules and incident response, teams need an effective Opsgenie migration strategy.

Quick Answer: Opsgenie End of Life (EOL) Facts

Final Shutdown Date: April 5, 2027. Support ends and Atlassian deletes all remaining data.
New Subscription Cutoff: June 4, 2025. No new trials or accounts after this date.
Pricing Reality: Many Opsgenie replacements cost more. With All Quiet, you typically gain modern features and reduce spend. See the Uberspace customer story.
Official Atlassian Path: Jira Service Management (JSM) serves as the migration destination for existing Atlassian customers.

Opsgenie Migration Timeline: Key Dates

Plan your budget and vendor selection according to these critical milestones.

Date	Changes	Action Item
June 4, 2025	Sales end for new subscriptions.	Finalize your vendor shortlist.
October 2025	Early shutdowns for some JSM users.	Begin data export for integrated accounts.
April 17, 2026	Potential read-only restrictions.	Test your parallel alerting system.
April 5, 2027	Service shutdown and end of support.	Complete all migration tasks.
Post-April 2027	Atlassian deletes all customer data.	Archive all audit logs and history.

Top Opsgenie Alternatives for 2026

Smart teams use this transition to rethink their incident management stack. Use this comparison to find the best fit for your organization.

Tool	Pros	Cons	Best For	Complexity
All Quiet	Calm alerting, simple setup, clear pricing.	Focuses on essential agility over bloat.	Teams of all sizes looking for clarity and simplicity in their incident response workflows.	Low
JSM	Official Atlassian path, ticketing focus.	High administrative overhead and costs.	Atlassian-heavy enterprises.	High
PagerDuty	Mature ecosystem, deep automation.	Expensive and often noisy.	Large scale enterprises.	High
Rootly	Excellent Slack-first coordination.	Requires a separate paging layer.	Workflow-centric teams.	Medium
incident.io	Great incident coordination, templates, timelines, and retros.	Paging/on-call needs to be added as paid add-on.	Product/engineering teams improving incident process maturity.	Medium

What to Look For When Replacing Opsgenie

Migrate your intent, not your chaos.

Evaluate alternatives based on these critical factors to ensure your next tool provides a genuine upgrade:

Noise Control: Look for grouping, deduplication, and precise routing.
Usability: Ensure schedules and overrides remain simple to manage.
Workflow Integration: Link alerts to resolutions within a single interface.
Migration Surface: Prioritize tools with API coverage and Terraform support.
Total Cost: Consider admin time and cognitive load, not just the bill.

Deep Dive: The Best Opsgenie Alternatives

All Quiet: The Modern Choice for Lean Teams

Many teams find that legacy tools increase cognitive load during incidents. All Quiet takes a different approach. We designed the product to reduce noise, keep integrations tight, and make on-call schedules predictable again.

Teams migrating to All Quiet benefit from:

Rapid Onboarding: Configure your organization without a dedicated owner.
Unified Flow: Manage the full lifecycle from alert to status pages.
Noise Suppression: Use smart grouping to prevent alert fatigue.
Clear Total Cost of Ownership (TCO): Reduce your total cost of ownership with transparent pricing and lean setup.

Compare All Quiet vs Opsgenie

Opsgenie Migration Resources

If you're actively migrating, these posts go deeper on strategy and implementation:

Jira Service Management: The Official Path

Atlassian moves Opsgenie features into Jira Service Management. This path works for organizations that prioritize ITSM processes and ticket-based operations. However, ticketing platforms often pull teams into heavy processes that can slow down incident response.

Compare All Quiet vs Jira Service Management (JSM Premium)

PagerDuty: The Enterprise Standard

PagerDuty offers a mature ecosystem with deep automation. It suits large organizations with massive scale. The primary challenge is complexity: without strict governance, teams often recreate the noise issues they intended to solve. In practice, a lot of teams only need a fraction of the platform (often ~20% of the features), but still have to pay the full price.

Compare All Quiet vs PagerDuty

Specialized Coordination: Rootly and incident.io

These tools focus on Slack-first coordination and post-incident hygiene. They excel at workflow maturity but treat on-call as an expensive paid add-on.

Compare All Quiet vs Rootly
Compare All Quiet vs incident.io

Practical Opsgenie Migration Checklist

Treat your migration as a parallel-run project to minimize risk during the transition.

Audit: Inventory all current teams, integrations, and routing rules.
Export: Save your on-call history and audit logs early.
Model: Choose between a ticket-first (ITSM) or engineering-first (Alerting) model.
Parallel Run: Route alerts to Opsgenie and your new tool to verify configuration.
Validate: Run game days to test escalations and ownership.
Cutover: Switch integrations one at a time with clear rollback steps.
Shutdown: Confirm all data is archived before the 2027 deletion.

Final Thoughts

The Opsgenie EOL deadline is an opportunity to move toward a calmer incident response culture. If you need a replacement that is fast to deploy and designed to reduce cognitive load, All Quiet is built for this moment.

Tool	Pros	Cons	Best For	Pricing	Complexity
All Quiet	Simple setup, integrated workflows, unlimited notifications, low TCO	Not built for extreme enterprise customization	Small–mid teams, startups, scaleups	Standard: $4.99/user/mo · Pro: $9.99 · Enterprise: custom	Low
PagerDuty	Enterprise-grade workflows, deep integrations, reliable alerting	Expensive, complex, noisy if not tuned	Large enterprises, SRE-heavy orgs	Free · Professional: $21/user/mo · Business: $41 · Enterprise: custom	High
Opsgenie (deprecated 2027)	Strong inside Atlassian ecosystem, solid alerting	Deprecation risk, Jira lock-in, migration required	Jira-centric teams (short-term)	Free · Essentials: $9.45/user/mo · Standard: $19.95 · Enterprise: $31.90	Medium
ilert	Strong uptime monitoring, EU hosting, AI-assisted workflows	Expensive, add-ons increase cost	Monitoring-heavy teams, EU compliance	Pro: €19/user/mo · Scale: €39 · Enterprise: €49	Medium–High
Zenduty	Highly customizable workflows, strong Slack/Teams integration	Complex setup, higher learning curve	Large support orgs, multi-team setups	Starter: $5/user/mo · Growth: $14 · Enterprise: custom	High

Feature	All Quiet	Notes
Simple, intuitive setup	✅	No multi-day configuration needed
Integrated workflows	✅	Alerts → triage → resolution in one flow
Noise reduction	✅	Designed to prevent alert fatigue
Fast onboarding	✅	New engineers can use it immediately
Transparent pricing	✅	No surprise add-ons
Enterprise-grade complexity	❌	Not built for extreme customization (by design)

Plan	Price (per user/month)	Best For	Key Features
Standard	$4.99	Small teams	Unlimited users, incidents, integrations, SMS/phone/email/push alerts, all monitoring types, on-call schedules, escalation policies, mobile apps
Pro	$9.99	Multi-team orgs	Everything in Standard plus: status pages, OIDC + SCIM, Terraform provider, public REST API, cross-team collaboration, advanced reporting
Enterprise	Custom	Larger orgs with compliance needs	Everything in Pro plus: advanced auditing/logging, custom onboarding, dedicated success channel, custom billing

Feature	PagerDuty	Notes
Simple, intuitive setup	❌	Setup can take days or weeks
Integrated workflows	✅	Strong, but often requires tuning
Noise reduction	❌	Can be noisy without careful configuration
Fast onboarding	❌	Steeper learning curve
Transparent pricing	❌	Add-ons increase cost quickly
Enterprise-grade complexity	✅	Built for large orgs

Tier	Price (per user/month)	Notes
Free	$0	Limited features
Professional	$21	Basic on-call + alerting
Business	$41	Advanced workflows + analytics
Enterprise	Custom	Full automation + enterprise support

Feature	Opsgenie	Notes
Simple, intuitive setup	❌	Setup depends heavily on Jira structure
Integrated workflows	✅	Strong inside Atlassian only
Noise reduction	❌	Alert logic tied to Jira rules
Fast onboarding	❌	Requires Jira familiarity
Transparent pricing	❌	Bundled with Atlassian plans
Enterprise-grade complexity	✅	Good for large Jira orgs

Tier	Price (per user/month)	Notes
Free	$0	Basic alerting
Essentials	$9.45	Limited workflows
Standard	$19.95	Most features
Enterprise	$31.90	Advanced integrations

Feature	ilert	Notes
Simple, intuitive setup	❌	More configuration required
Integrated workflows	✅	Monitoring + on-call combined
Noise reduction	❌	Can be noisy with many monitors
Fast onboarding	❌	More complex than newer tools
Transparent pricing	❌	Higher cost tiers
Enterprise-grade complexity	✅	Strong monitoring depth

Tier	Price (per user/month)	Notes
Pro	€19	Core features
Scale	€39	Larger orgs
Enterprise	€49	Compliance + support

Feature	Zenduty	Notes
Simple, intuitive setup	❌	Steep learning curve
Integrated workflows	✅	Highly customizable
Noise reduction	❌	Requires careful tuning
Fast onboarding	❌	Complex interface
Transparent pricing	✅	Clear tiers
Enterprise-grade complexity	✅	Very flexible

Tier	Price (per user/month)	Notes
Starter	$5	Basic alerting
Growth	$14	Most features
Enterprise	Custom	Advanced workflows

PagerDuty’s 83% Stock Drop Since 2019 and What We Learned from It in 2026

Mads Quist — Tue, 02 Jun 2026 10:21:00 +0000

There’s nothing like a good old fashioned budget review to remind you what you’re actually spending money on… and how much of it.

PagerDuty is one of those tools that makes you do a double-take when you open the invoice. You ask yourself: “Is this the monthly or the annual figure?” while wondering if either would even be acceptable.

This collective eyebrow raise isn’t because PagerDuty is bad software, but because the world around it changed while PagerDuty stayed the same.

To understand what happened, you have to look at the bigger picture; the world around PagerDuty that evolved while it remained static. Let’s see how their story unfolds.

Act I: Setting the scene

PagerDuty IPO’d in 2019 and by 2021 it was trading around $34. It came onto the scene like the big brother of incident response, knowing it had nailed a problem that everyone else was either ignoring or still trying to solve. PagerDuty was reliable; the kind of tool you bought to show off that you had your operational act together.

Fast-forward to 2025/2026 and it’s suffered a multi-year collapse with a 73% decline over 5 years. For a while, the market was all about PagerDuty, but then it did what it normally does: it changed its mind.

In November 2025, PagerDuty’s stock plummeted 24% in a single day. Their team had waved a small victory flag while publishing their Q3 results with GAAP profitability for the second straight quarter, which was great news! Until they pulled back their revenue guidance because of customers cutting seats and watching their budgets.

Sure, the financial housekeeping seemed cleaner, as their margins were improving on the surface and EPS was behaving as it should. But then the curtain was drawn: they lowered their growth expectations and analysts went straight for the jugular. Suddenly, everyone was wondering whether PagerDuty could even keep its revenue engine running at the pace Wall Street expected.

If your on-call alerts dropped this hard, you’d file an incident report.

Act II: Enterprise pricing in a market that’s lost confidence

I don’t want to sugar-coat it. PagerDuty’s pricing has always been aspirational. They’ve positioned themselves as enterprise-grade, while CTOs increasingly see them as enterprise-inflated. It’s the kind of pricing that assumes you have a huge team, an even bigger budget and an extremely forgiving CFO (or one who’s asleep on the job).

This approach worked for years, though. Enterprise pricing was part of the deal for DevOps starter packs, but then the pendulum swung. Seat-based pricing is now under more pressure than ever before. Analysts even said that seat license compression and slowing ARR growth were key factors in PagerDuty’s revenue slowdown.

In other words, customers were trimming their usage rather than expanding it. But why do that when you can let the system take care of the groundwork for you? A huge amount of alert handling is just repetition: checking if the alert is real, gathering context, matching it to other signals, rinse and repeat. But a solid system can filter out the junk and enrich alerts with the right information, then connect related events and trigger the fixes. You instantly cut down on noise, along with 70% of security investigations.

You can’t replace your analyst, but you absolutely can clear the fog so they can focus on alerts that matter.

Act III: Do you really need the Cadillac?

While PagerDuty was busy expanding its platform, modern alternatives were slowly creeping up on it with better open-source tools, more mature cloud providers and bootstrapped SaaS tools. Suddenly, you could get 80-90% of PagerDuty’s core functionality without paying enterprise prices.

This wasn’t a symptom of PagerDuty being copied by competitors, but incident response itself becoming a solved problem. Cloud-native alerting like AWS, GCP and Azure had matured dramatically, while open-source tools like Alertmanager continued to get better and better. They were offering alerting pipelines that, five years ago, would’ve looked like something from Futurama.

Incident response suddenly had flat pricing, transparent billing, no per-seat penalties and support teams that actually answered emails. Meanwhile, PagerDuty was still innovating. They rolled out AI-driven automation and workflow orchestrations, and even reported that 825 customers were spending $100k+ ARR in Q3 2024.

But does innovation erase the pricing gap for lean teams?

Big, fat no. And that’s when migrations start to happen.

Act IV: The not-so-quiet migration

If you want to really understand the shift in the market, go to the belly of the beast. Look at Slack channels, look at Reddit threads–go to the very places where engineers actually tell the truth. You’ll see common themes emerging in the DevOps community and messages like:

“We switched and nothing broke.”
“We were paying for features we never used.”
“We were punished with higher prices for growing.”
“We replaced it with a lightweight SaaS and cloud-native tool.”

The reality is that companies weren’t fighting back or even arguing with PagerDuty. They simply… moved on. They realized that they, in fact, didn’t need the Cadillac. They turned away from longer sales cycles and SMB-weakness, towards cheaper software that worked well and didn’t require a whole board meeting to approve.

Act V: The lean, mean, incident response machines

Call the news stations, everyone; the bootstrapped competitors are having their moment in the sun. Incident response is entering a new era and the winners aren’t the biggest, shiniest platforms with features pouring out of the box. They’re the ones offering:

Flat pricing
Transparent billing
Faster support
No need to justify their existence every fiscal year
Alignment with modern engineering teams
No pressure to satisfy Wall Street.

PagerDuty’s 52-week low of $13.94 in 2025, a 34.67% YoY drop, wasn’t a failure, but a sign of customer and investor uncertainty. It proved that the old model of “enterprise pricing for everyone” simply wasn’t the go-to anymore. And unless companies are willing to evolve in line with that reality, they’ll fade into the background of those that thrive in the next decade.

Final act: What this means for the future of incident response
The incident response market is going through a big personality change. It’s moving from enterprise-first to developer-first, with big platforms, big bundles and big invoices. PagerDuty is a case study in what happens when pricing strategy diverges from customer value. If the bill keeps climbing but the value doesn’t, customers won’t bother complaining about it. They’ll just leave.

And here’s the twist: even though multiple DCF analyses suggest PagerDuty is undervalued by 50-55%, investors still question its growth prospects. The future of incident response will be defined by tools that don’t overcharge or overcomplicate, and simply do what they say they’ll do without making you expense a limb.

So are you paying for product or public market overhead?

An 82.8% stock-drop isn’t something investors will bat their eyelids at. A fall that hard forces customers to rethink what they’re actually paying for: the product? The innovation? The reliability? Or just the cost of being a public company with slowing growth and rising pressure?

And not just customers, but CTOs too. They’re evaluating whether they’re using the features they pay for and if the pricing model makes sense for how their teams work today. They want to know if the vendor is stable enough to bet their operations on and what the ROI is compared to the alternatives (or just building it themselves).

Your on-call budget shouldn’t be keeping you up at night. You’ve got enough alerts for that. But if you want a quieter life with less interruptions, talk to us today.

Beyond Vibe-Coding

Mads Quist — Thu, 28 May 2026 10:59:00 +0000

Are You Paying for Reliability or Hype in the Age of Vibe-Coding and SaaS Subscriptions?

In 2026, many engineering teams are coming to terms with an odd new reality: a growing percentage of their codebase wasn’t written by their own team… or even a human, for that matter.

Rather than being pair-programmed, reviewed, tested, or even fully understood, it was AI-generated. Confidently, instantly, and sometimes a little chaotically, by something that simply “felt” like the code would work. In other words, it operates off vibes, not knowledge.

Welcome to the era of vibe-coding.

Big companies like Microsoft and Google are already using AI to write 30% of their code. And it doesn’t exactly get the code wrong; it runs well, passes all the necessary tests, and even looks good enough that no one questions it. Until it behaves unexpectedly, that is.

AI is making code shipping even easier than it ever was, but that doesn’t come for free: Day 2 operations are slowly becoming a nightmare, because when no one remembers writing the code, no one remembers how to fix it.

It’s time like these where the conversation shifts from productivity to practicality, and more importantly, reliability. And that leads us to the question: is your incident management setup built to survive the new world you’re operating in?

The Hidden Cost of Vibe-Coding for Day 2 Operations

I know what you’re thinking: yes, you absolutely can, and in some cases maybe you should, generate a lot of working code quickly and efficiently with AI. It’s a fast, confident solution that’s great when you’re prototyping, but much less great when you’re trying to understand why a service is suddenly swallowing 40% more memory on Thursdays.

In fact, AI-generated code produces 1.7x more issues than human-written code. And relying fully on it is where many teams seem to go wrong. They end up creating things too fast with very little specification and run into a mountain of problems before the new code is even out of the box. But the truth is very simple:

_AI has made writing code easier. But it hasn’t made owning that code any easier.
_
Instead, it’s introduced an onslaught of new problems for engineering managers and VPs, like:

More edge-case failures
More “no one touched this, why did it break?” moments
More debugging sessions
More operational load on teams who didn’t write, or understand, the original logic.

Code is the foundation of how online services work. If the codebase becomes a black box, your incident management becomes the only reliable source of truth.

Why Your Incident Management Can’t Live on the Same Servers as Your App

Enter: the build-vs-buy conversation. Plenty of teams have built their own alerting systems over the years and it’s easy to understand why. Engineers are good at building things and alerting seems simple enough.

But the slightly uncomfortable reality is that if your alerting lives on the same infrastructure as your application, it’ll fail the same way your app fails. One single issue can cascade across multiple services, so when your platform goes down, your homegrown alerting goes with it. Identifying the root cause of the problem is like looking for a needle in a haystack, as any issues faced during development might not be reproducible in the production environment.

Imagine using the foundation of your house to build a new roof. That’s what happens when your alerting and infrastructure co-exist in the same place. External, independent alerting isn’t a luxury, but a safety measure. If your cloud provider hiccups, your alerts hiccup with it. And if your AI-generated deployment throws a tantrum, your DIY alerting gets pulled into the meltdown.

Separating the two means only having to deal with one catastrophe rather than two. It guarantees that when your platform is collapsing, your incident management (and engineering team) isn’t joining it.

The New Reality of Build vs Buy in 2026

Engineering teams are perfectly capable of building their own alerting systems. They can even build databases, authentication systems, and CI/CD pipelines from scratch… but do they even want to? Are homegrown systems as reliable as plug-and-play?

That’s where the build-vs-buy conversation gets more interesting. It’s more than just a cost comparison; it’s a question of control, scalability and integration. Building gives you bespoke tools that do exactly what you need them to do, and are operationally efficient. Buying, on the other hand, is standardized and easy; there’s no maintenance costs, as those sit with the provider, and security is almost guaranteed.

Plus, DIY alerting comes with a few unavoidable truths:

It shares the same failure modes as your platform
It depends on the same infrastructure
It inherits the same outages
It expands your operational surface area
It becomes one more thing to maintain when maintenance is already hard enough.

Layer on the unpredictability of vibe-coded systems with incidents that are still less predictable and harder to solve, and the last thing you want to deal with is an alerting system that disappears the moment you need it most.

That’s where All Quiet steps in as the adult in the room.

Why All Quiet is Built for the World Vibe-Coding Created

All Quiet isn’t trying to be a fancy, flashy tool. It does what it says on the tin: keeps alert management quiet. It’s not trying to reinvent incident response with buzzwords or magic tricks; it’s built around one very simple and boring, yet extremely important, principle:

_Your alerting should stay independent when everything else goes offline. _

Nice and simple. And that principle shapes everything about how All Quiet works:

It runs independently from your infrastructure, so your alerts don’t vanish just because your servers took a last-minute holiday.
It has different failure modes, meaning your app can crash, your cluster can melt, your cloud can create a hurricane, and All Quiet doesn’t bat an eyelid.
It doesn’t rely on your servers, cloud provider or deployment pipeline, so your alerting isn’t married to the same weak dependencies as your product.
It doesn’t care if your AI-generated code crashed your entire platform, because it won’t be affected by the fallout.
It’s designed to be the one stable thing in a house that’s falling down, because it doesn’t panic while everything does.

AI-generated code means people don’t fully understand the very code they’re working with, so reliability becomes the only differentiator. You can have all the fancy dashboards and features you want, but they’re worth nothing if an incident creeps up and your code is hidden away in a treasure chest no one has the keys to.

All Quiet is built to be reliable in every situation. When things are calm, it’s calm. When things are less calm, it’s calm. And where your entire system is swirling into a vortex of chaos and fire, it’s still calm. When vibe-coding has taken over the world, the last thing you want is an alerting system that runs solely on vibes too.

SaaS Cost Optimization in the Vibe-Coding Age

There are thousands of SaaS tools out there, and hundreds of alerting tools. But there’s a new kind of bloat on the rise: tools that look great on paper but only exist because your AI-generated code keeps spitting out surprises.

Engineering leaders are asking themselves smarter questions: What’s actually mission-critical? What’s just hype? What’s duplicating functionality? What’s costing us more than it’s saving us?

But most importantly:

_What’s the cost of downtime if our alerting fails with everything else? _

The most expensive tool in your stack is the one that doesn’t work when you need it most. All Quiet isn’t about adding another subscription to your balance sheet, but removing uncertainty and wasted time from your operational risk.

The Future of Reliability Over Hype

AI is like a self-cleaning oven. It’s getting smarter and better, which means vibe-coding will keep getting weirder. But engineering teams will keep shipping faster than ever.

Despite that, the fundamentals won’t change: you still need to know when something breaks and you need to respond quickly.

And you’ll always need an alerting system that doesn’t disappear the moment your platform does. Your team shouldn't be asking which tool has the most features, but which tool will still be standing when everything else fails.

And the only answer is the one that doesn’t run on vibes too. It’s the one that does what it says it’ll do, and it does it independently of everything else.

Which is exactly what All Quiet does. Talk to us today to find out how.

SaaS is dead, long live SaaS

Mads Quist — Tue, 26 May 2026 09:59:00 +0000

While vibe-coding does favor build over buy for some products, it won't replace mission-critical tools in the foreseeable future

Here’s my take on what gets killed, what survives, and the build-vs-buy rule that actually works:

I believe that AI does not kill SaaS. It eliminates the “thin wrapper”: software that offers little more than a polished UI for simple automations. Today, any developer can stitch these tools together in an afternoon.

Still, SaaS is not disappearing; it is evolving. While products that sell mere convenience will face extinction, products that sell reliable outcomes for high-stakes problems will thrive. This guide covers what survives the shift toward vibe-coding and how to decide whether to build or buy.

The New Baseline: When "Good Enough" Becomes Free
Vibe-coding is great: It allows us to ship functional software at unprecedented speeds. Large Language Models (LLMs) now draft code, connect APIs, and generate UI scaffolding automatically.

We can see that this shift raises the bar for SaaS vendors. When basic functionality is cheap, the value of a paid tool must come from reliability, compliance, and long-term maintenance. High prices do not just signal quality. They create a financial incentive for teams to build their own "80% solution." Just look at the stock price of tools like PagerDuty or Hubspot or other SaaS giants that have seen their stock prices drop significantly.

SaaS Categories Facing Extinction

That said, I think vulnerable SaaS categories share three traits: a narrowly defined job-to-be-done, low failure costs, and easily verifiable outputs. Good examples are:

Workflow Wrappers: Basic CRUD (Create, Read, Update, Delete) tools for internal approvals or team dashboards.

Low-Stakes Content: Tools for text summarization, formatting, or template generation.

Basic Analytics: Simple data visualization layers that sit on top of a data warehouse.

So, how do SaaS players stay relevant? They need to be outstanding in the categories that are not vulnerable to vibe-coding.

The Survivors: Infrastructure You Trust

Based on the criteria mentioned above, my strong opinion is that SaaS products that sustain are those where the cost of being wrong is high. These are not features: they are mission-critical infrastructure.

1. Systems of Record and Compliance

When audit logs, access controls, and data retention are legal requirements, a vibe-coded script is not an acceptable answer to an auditor. Specialized SaaS platforms provide the security posture and regulatory guarantees that custom-built scripts lack.

2. High-Availability Operational Tools

If a system failure must wake an engineer at 2 a.m., the tool must be battle-tested. Incident management is the primary example. Reliability is the core feature.

In this category, vibe-coding errors are not cosmetic. They are existential. Failing to page the right person during a critical outage results in lost revenue and broken trust. All Quiet and other incident response systems offer reliability that a prototype cannot guarantee. And this guarantees are mission-critical.

There’s also an architectural reality: your incident management tool must keep working when you are down. If you self-host it on the same infrastructure, identity provider, or network dependencies as your primary systems, you will lose alerting precisely when you need it most. The whole point is having a system that is on high alert when you aren't to let you know when something is broken. Running incident management as a truly independent system (even when self-hosted) adds meaningful overhead, which is one more reason teams often prefer buying a dedicated service built to stay up during your worst day.

3. Complex Integration Ecosystems

Last but not least: integration ecosystems. Yes, AI can reduce some glue code and speed up building custom connectors. But the real pain is rarely the first implementation — it’s the ongoing reliability work: API changes, new auth flows, rate limits, subtle edge cases, and “it worked yesterday” incidents when a vendor ships an update. In practice, you usually can’t just delete integrations without deleting requirements. When a tool sits in the middle of many other tools, you’re effectively signing up to maintain that surface area for years. SaaS vendors sell the promise that these connections keep working without your team babysitting them.

The Build-vs-Buy Decision Matrix

Factor Build (Vibe-Coding) Buy (SaaS)
Risk of Failure Low (Embarrassing) High (Expensive/Existential)
Ownership Internal Team Vendor (SLA-backed)
Verification Obvious and Simple Subtle and Critical
Integrations 1 or 2 Static APIs Many Evolving Vendors

Final Rule of Thumb

Build if vibe-coding achieves your outcome with acceptable risk for your business. Buy if the operational burden or maintenance will quietly exhaust your team because you need the product to be battle-tested.

Modern SaaS wins when it removes long-term risk, not when it adds more features. You’re paying for reliability, security, compliance, and support, ensuring that the tool still works when your team is tired, busy, or in the middle of an outage.

AI makes building prototypes cheap. What doesn’t get cheap is owning the consequences: keeping it up, keeping it secure, keeping integrations working, and maintaining it for years. If you’re not willing to own that long-term responsibility, buy and focus your resources on building your core product.

Migrating from Opsgenie to All Quiet: A Full Terraform-First Guide

Mads Quist — Tue, 12 May 2026 15:33:44 +0000

Originally published on 12 May 2026 on the All Quiet Tech Blog.

If your Opsgenie config already lives in Terraform, you can migrate methodically instead of clicking two consoles side by side. This guide translates users, teams, integrations, on-call schedules, escalations, and routing into All Quiet - complete with example HCL, migration checklist, and tips for running both tools in parallel before you switch.

With the recent changes in the Atlassian ecosystem, many SRE and DevOps teams are finding themselves at a crossroads: adapt to the increasing complexity of Jira Service Management (JSM) or move to a leaner, more focused incident management platform.

At All Quiet, we believe incident management should stay close to the code. That's why our platform is built to be managed via Terraform from day one. In this guide, we'll walk through a complete technical migration from Opsgenie Terraform resources to All Quiet, resource by resource, with real HCL on both sides.

If you are still weighing vendors before you change tooling, start with our overview of All Quiet as an Opsgenie alternative, then use this article for the Terraform resource mapping and cutover checklist.

Why a Terraform-First Migration?

If you're already managing Opsgenie via Terraform, you have an advantage: your entire on-call configuration is already codified. Rather than clicking through two UIs in parallel, you can translate your .tf files directly from one provider to the other, terraform plan the result, and cut over with confidence.

The Strategy: "Logic-First" Migration

In Opsgenie, configuration is fragmented across six or more resource types: opsgenie_user, opsgenie_team, opsgenie_api_integration, opsgenie_schedule, opsgenie_schedule_rotation, and opsgenie_escalation. All Quiet centralizes this logic into fewer, more cohesive resources, most notably allquiet_team_escalations, which unifies schedules, rotations, and escalation policies into a single resource that can't get out of sync.

Here's the full resource mapping at a glance:

Opsgenie Resource	All Quiet Resource	Notes
`opsgenie_user`	`allquiet_user`	Standalone identity
`opsgenie_team`	`allquiet_team` + `allquiet_team_membership`	One membership resource per user–team pair
`opsgenie_api_integration`	`allquiet_integration`	Team-owned, strongly typed
`opsgenie_schedule`	`allquiet_team_escalations`	Merged into unified resource
`opsgenie_schedule_rotation`	`allquiet_team_escalations`	Rotations live inside escalation tiers
`opsgenie_escalation`	`allquiet_team_escalations`	Rules become escalation tiers
(routing within integration)	`allquiet_routing`	Explicit routing resource

1. Setting Up the Providers

First, initialize your environment. You'll need your All Quiet API Key, which you can generate in Organization Settings > API Keys (requires Owner or Administrator role). See our Terraform setup docs for the full walkthrough.

terraform {
  required_providers {
    allquiet = {
      source  = "AllQuietApp/allquiet"
      version = ">= 3.0.0"
    }
  }
}

provider "allquiet" {
  api_key    = var.allquiet_api_key
  api_region = "eu" # or "us" — must match your organization's data region
}

variable "allquiet_api_key" {
  type      = string
  sensitive = true
}

Tip: We recommend creating your organization with a shared admin account (e.g., admin@company.com) rather than a personal email. This way, every "real" on-call user can be provisioned via Terraform, and you won't have a chicken-and-egg problem with the account that created the org.

2. Teams, Users, and Memberships

In Opsgenie, users are standalone resources with roles, and team membership is defined inline within the team. This creates tight coupling, changing a user's team membership means editing the team resource.

All Quiet separates these concerns into three distinct resources: the team, the user identity, and the membership link between them. Each membership is its own resource (allquiet_team_membership), one resource per user–team pair. This allows for cleaner state management: adding or removing a single member doesn't trigger a plan change on the team or on any other member.

The Opsgenie Way:

resource "opsgenie_user" "sre_lead" {
  username  = "alex@company.com"
  full_name = "Alex Rivera"
  role      = "user"
  timezone  = "Europe/Berlin"
}

resource "opsgenie_team" "devops" {
  name        = "DevOps"
  description = "Core DevOps and SRE team"

  member {
    id   = opsgenie_user.sre_lead.id
    role = "admin"
  }

  member {
    id   = opsgenie_user.backend_eng.id
    role = "user"
  }
}

The All Quiet Way:

# 1. Define the team
resource "allquiet_team" "devops" {
  display_name = "DevOps"
  time_zone_id = "Europe/Berlin"
}

# 2. Define user identities
resource "allquiet_user" "sre_lead" {
  email        = "alex@company.com"
  display_name = "Alex Rivera"
}

resource "allquiet_user" "backend_eng" {
  email        = "jordan@company.com"
  display_name = "Jordan Lee"
}

# 3. Link each user to the team via a dedicated membership resource (one per user–team pair)
resource "allquiet_team_membership" "devops_sre_lead" {
  team_id = allquiet_team.devops.id
  user_id = allquiet_user.sre_lead.id
  role    = "Administrator" # "Administrator" or "Member"
}

resource "allquiet_team_membership" "devops_backend_eng" {
  team_id = allquiet_team.devops.id
  user_id = allquiet_user.backend_eng.id
  role    = "Member"
}

What changed:

Opsgenie's admin / user team roles map to All Quiet's Administrator / Member.
Each membership is its own resource (allquiet_team_membership), so adding or removing a single team member is a targeted change, no cascading diffs on the team or other members.
Users provisioned via Terraform receive an invite to set their password. If you use SSO (OIDC, Google, or Microsoft), configure that first, see the SSO docs.

3. Integrations: Team-Owned and Strongly Typed

Opsgenie requires separate resources for API integrations and their subsequent notification or routing actions. The integration itself is often a loose endpoint that you wire to teams via responders blocks.

All Quiet treats integrations as team-owned endpoints with strongly typed integration types, so there's no guesswork about payload format.

The Opsgenie Way:

resource "opsgenie_api_integration" "grafana" {
  name              = "Grafana-Alerts"
  type              = "Grafana"
  owner_team_id     = opsgenie_team.devops.id
  enabled           = true
  allow_write_access = true

  responders {
    type = "team"
    id   = opsgenie_team.devops.id
  }
}

The All Quiet Way:

resource "allquiet_integration" "grafana" {
  team_id      = allquiet_team.devops.id
  display_name = "Grafana Production"
  type         = "Grafana"
}

That's it, no responders block, no allow_write_access flag. The integration belongs to the team, and the team's escalation policy handles notification logic.

Common type mappings:

Opsgenie type	All Quiet type
Datadog	Datadog
Prometheus	Prometheus
Grafana	Grafana
CloudWatch	AmazonCloudWatch
API / Webhook	Webhook

The full list of supported integration types is available at: https://allquiet.app/api/public/v1/inbound-integration/types

Important: Treat the integration type and team assignment as fixed once created, changing them may require destroying and re-creating the resource, which generates a new webhook URL. Plan these carefully. After terraform apply, the new webhook URL will be available. For each supported inbound integration type you can download a default Terraform snippet for payload mapping: use https://allquiet.app/api/integrations/terraform/default/<Type>.tf where <Type> is the exact integration type identifier (see the inbound integration types list above). For example, Datadog is https://allquiet.app/api/integrations/terraform/default/Datadog.tf; Grafana, Webhook, AmazonCloudWatch, and every other supported type follow the same URL pattern with their own type name.

If you need to customize how payloads map to incidents (e.g., extracting severity from a specific JSON field), use the allquiet_integration_mapping resource. If you don't define one, All Quiet uses sensible defaults for each integration type. The mapping supports JSONPath, XPath, regex, and static values and every incident maps to three key attributes: Status (Open/Resolved), Severity (Minor/Warning/Critical), and an optional Title.

Migration tip: You can run both Opsgenie and All Quiet integrations in parallel during the transition period. Point your monitoring tools at both webhook URLs until you're confident in the All Quiet setup.

4. On-Call Schedules and Escalations: The Unified Resource

This is the most significant architectural difference between the two providers, and the biggest win in your Terraform-first migration.

In Opsgenie, on-call configuration is spread across three separate resources that reference each other by ID. In All Quiet, it's all one resource: allquiet_team_escalations. This resource follows a clear hierarchy: Escalation Tiers → Schedules → Rotations, which mirrors how on-call actually works: you have layers of people to notify (tiers), each layer has time-based coverage windows (schedules), and people rotate through those windows (rotations).

The Opsgenie Way (3 resources, fragile cross-references):

resource "opsgenie_schedule" "devops_oncall" {
  name          = "DevOps On-Call"
  timezone      = "Europe/Berlin"
  enabled       = true
  owner_team_id = opsgenie_team.devops.id
}

resource "opsgenie_schedule_rotation" "devops_weekly" {
  schedule_id = opsgenie_schedule.devops_oncall.id
  name        = "Weekly Rotation"
  type        = "weekly"
  length      = 1
  start_date  = "2024-01-01T09:00:00Z"

  participant {
    type = "user"
    id   = opsgenie_user.sre_lead.id
  }

  participant {
    type = "user"
    id   = opsgenie_user.backend_eng.id
  }
}

resource "opsgenie_escalation" "devops_escalation" {
  name          = "DevOps Escalation"
  owner_team_id = opsgenie_team.devops.id

  rules {
    condition   = "if-not-acked"
    notify_type = "default"
    delay       = 5

    recipient {
      type = "schedule"
      id   = opsgenie_schedule.devops_oncall.id
    }
  }

  rules {
    condition   = "if-not-acked"
    notify_type = "default"
    delay       = 15

    recipient {
      type = "user"
      id   = opsgenie_user.manager.id
    }
  }

  repeat {
    wait_interval          = 30
    count                  = 3
    reset_recipient_states = true
  }
}

That's 3 resources, 50+ lines, with IDs threaded between them. Delete the schedule without updating the escalation and you get a dangling reference.

The All Quiet Way (1 resource, self-contained):

resource "allquiet_team_escalations" "devops_oncall" {
  team_id = allquiet_team.devops.id

  escalation_tiers {
    # TIER 1: On-call rotation — alert the person on duty
    repeats               = 3
    repeats_after_minutes = 5

    schedules {
      display_name = "DevOps Weekly Rotation"

      rotation_settings {
        rotation_mode      = "auto"
        auto_rotation_size = 1         # One person on-call at a time
        repeats            = "weekly"
      }

      rotations {
        members {
          team_membership_id = allquiet_team_membership.devops_sre_lead.id
        }
        members {
          team_membership_id = allquiet_team_membership.devops_backend_eng.id
        }
      }
    }
  }

  escalation_tiers {
    # TIER 2: If Tier 1 exhausts its repeats, escalate to the manager
    repeats = 1

    schedules {
      display_name = "Manager Escalation"

      rotations {
        members {
          team_membership_id = allquiet_team_membership.devops_manager.id
        }
      }
    }
  }
}

Everything that was spread across opsgenie_schedule, opsgenie_schedule_rotation, and opsgenie_escalation is now a single allquiet_team_escalations resource. Schedules and rotations live inside escalation tiers, so there's no way for them to become orphaned. Every person, whether they're in a rotating schedule or a single-person escalation target, is referenced via their team_membership_id, which keeps the dependency graph clean.

Key mapping:

Opsgenie concept	All Quiet equivalent
Escalation rule with delay	`escalation_tiers` with `repeats_after_minutes`
`opsgenie_schedule` (time windows)	`schedules` block within a tier, define on-call times (e.g., weekdays 08:00–18:00)
`opsgenie_schedule_rotation`	`rotation_settings` within a `schedules` block, auto or explicit mode
Rotation participants	`rotations` → `members` → `team_membership_id` (always via membership)
Multiple schedules for follow-the-sun	Multiple `schedules` blocks in the same tier, each covering different hours/days
`repeat` block on escalation	`repeats` on the relevant tier
Recipient: schedule	Tier with a `schedules` block containing rotations
Recipient: user	Tier with one schedule, one rotation, one member

Advanced patterns: Round-robin alerting distributes incidents evenly when multiple people are on-call simultaneously. On-call overrides, both personal and team-level, can be managed via the allquiet_on_call_override Terraform resource without touching the escalation config. See the escalation docs for the full set of options.

Note on complexity: Opsgenie's delay/repeat model and All Quiet's tier-level repeats / repeats_after_minutes / auto_escalation_after_minutes don't map one-to-one in every case. Simple escalations translate cleanly, but complex multi-rule Opsgenie policies may need case-by-case tuning. We recommend testing each escalation path with a synthetic incident before cutting over.

Note on time restrictions: Opsgenie's time_restriction blocks on rotations (time-of-day and weekday-and-time-of-day) map to All Quiet's schedule on-call times. In All Quiet, each schedule defines its active hours and days directly (e.g., "Monday–Friday, 09:00–17:00"), which is more intuitive than Opsgenie's separate restriction blocks. Review these during migration.

5. Routing: The Incident Traffic Controller

In Opsgenie, routing logic is often buried inside the integration itself (via responders blocks) or handled by notification policies. In All Quiet, routing is an explicit, first-class resource with a powerful rules engine. Each rule has three components: Conditions (when to trigger), Actions (what to do), and Channels (how to notify).

resource "allquiet_routing" "prod_alerts" {
  team_id      = allquiet_team.devops.id
  display_name = "Production Alert Routing"

  rules = [
    {
      # Mute Slack for test environment alerts, only send email
      conditions = {
        statuses   = ["Open"]
        attributes = [{ name = "Environment", operator = "=", value = "Test" }]
      }
      actions = {
        change_severity = "Minor"
      }
      channels = {
        notification_channels = ["Email"]
      }
    },
    {
      # For escalated critical incidents, also trigger the PagerDuty outbound webhook
      conditions = {
        statuses   = ["Open"]
        severities = ["Critical"]
        intents    = ["Escalated"]
      }
      channels = {
        outbound_integrations = [allquiet_outbound_integration.pagerduty_webhook.id]
      }
    }
  ]
}

Valid notification_channels values are "Email", "Push", "SMS", and "VoiceCall".

Routing conditions can filter on severity, status, specific integrations, incident intents (created, escalated, resolved), custom payload attributes, and even time-of-day restrictions. Actions include discarding incidents, changing severity, assigning to other teams (within an Organization), adding interactions, and delaying execution. This replaces Opsgenie's scattered notification policies with a single, auditable, version-controlled resource.

Pro tip: For multi-team setups, you can create a "root team" that owns your integrations and uses routing rules to fan out incidents to the appropriate team based on payload attributes. See the routing docs for detailed examples.

Migration Checklist

Here's the step-by-step order we recommend. The key dependency is that allquiet_team_membership requires both the team and user to exist, and allquiet_team_escalations references membership IDs, so teams, users, and memberships must all be in place before you build escalation tiers.

Set up the All Quiet Organization and generate your API key.
Create teams (allquiet_team) and provision users (allquiet_user). These two have no dependency on each other and can be created in any order or in parallel.
Link users to teams (allquiet_team_membership), one resource per user–team pair. This requires both the team and user to exist.
Create integrations (allquiet_integration) for each monitoring source. Note the new webhook URLs.
Customize payload mappings (allquiet_integration_mapping) if the defaults don't fit your payload structure.
Configure notification preferences (allquiet_user_incident_notification_settings), this controls how each user gets alerted (push, SMS, voice call, email) and with what delay.
Build escalation policies (allquiet_team_escalations) by merging your Opsgenie schedules, rotations, and escalation rules into unified tiers. Rotations reference team_membership_id, so memberships must exist first.
Set up routing rules (allquiet_routing) for any advanced alert routing.
Set up outbound integrations (allquiet_outbound_integration) for Slack, Microsoft Teams, or webhook notifications.
Run both systems in parallel, point your monitoring tools at both Opsgenie and All Quiet webhook URLs for a burn-in period. Trigger test incidents to verify the full notification chain.
Cut over, update webhook URLs to point only to All Quiet, then terraform destroy the Opsgenie resources.

Why Switch to All Quiet?

Bootstrapped and independent. We aren't beholden to Private Equity, Venture Capital firms or enterprise conglomerates. We build for SREs, not for quarterly earnings.
Infrastructure as Code, natively. Our Terraform provider isn't an afterthought, it's built to be the primary way you manage your on-call setup. Resources provisioned via Terraform are locked in the web app to prevent drift.
Cost efficiency. Stop paying the "Atlassian Tax." All Quiet provides the same high-availability alerting at a fraction of the cost, with a transparent pricing model.
Less fragmentation, less drift. Opsgenie spreads on-call logic across separate schedule, rotation, and escalation resources that reference each other by ID. All Quiet collapses that into a single allquiet_team_escalations resource, fewer cross-references means fewer ways for your Terraform state to diverge from reality.

Ready to simplify your stack? Check out our Terraform Provider documentation and start your migration today.

AWS Elastic IP failover with Keepalived: how we keep self-managed loadbalancers redundant

Mads Quist — Mon, 11 May 2026 16:28:24 +0000

Originally published on 10 May 2026 on the All Quiet Tech Blog.

At All Quiet we build incident management: alerting, on-call rotations, escalation, status pages, and integrations with the monitoring stacks teams already run. A meaningful slice of my job is keeping the boring edges boring, especially ingress, when something breaks.

In parts of our stack we run loadbalancers ourselves on EC2 instead of putting every path behind an AWS-managed balancer. We do that in part to avoid leaning too hard on higher-level AWS abstractions for those tiers: we still rely on EC2 for reliable virtual machines, and we keep the design close to portable building blocks so we could run the same pattern in another data center or provider without a ground-up redesign. Once we made that choice, we still had a plain high availability (HA) problem for the active-passive pair: keep the public edge redundant.

For those tiers we use a small pattern: a stable Elastic IP (EIP), the address we publish in DNS and the stand-in for a floating IP on a traditional network; Keepalived running Virtual Router Redundancy Protocol (VRRP) between peers; and the EC2 API, mainly AssignPrivateIpAddresses and AssociateAddress, to move that EIP when mastership changes. We wire this with Ansible and the AWS Cloud Development Kit (CDK) in our infrastructure repo.

The problem in AWS terms

I grew up with patterns where a “floating IP” moves at layer 2 (L2) with gratuitous Address Resolution Protocol (ARP). Amazon Virtual Private Cloud (VPC) doesn’t work like your favorite rack fabric: public routing for Elastic IPs is enforced by AWS’s control plane, tied to a specific Elastic Network Interface (ENI) and private address on an instance.

So we split responsibilities deliberately:

Between our servers, we use Keepalived / VRRP, almost always unicast, to decide which node is primary.
Against AWS, we run a script on notify_master that calls the command-line interface (CLI) or API so the EIP actually attaches to the winner.

If we did only VRRP virtual-address tricks without AssociateAddress, we would not fix customer-visible public routing for that EIP. If we did only API moves without Keepalived, we’d lack a clean distributed agreement story on the pair. We need both layers.

Architecture at a glance

                    Elastic IP (stable in DNS)
                              │
                              ▼
              ┌───────────────────────────────┐
              │  EC2: EIP associated here     │
              │  (AssociateAddress, etc.)     │
              └───────────────────────────────┘
                              │
                  Our LB tier (e.g. HAProxy / nginx)
                              │
                           backends

On both nodes we run Keepalived with unicast peers, priorities, and a vrrp_script that reflects whether our LB process is actually alive (systemctl, curl to localhost, or whatever probe matches reality). When a node becomes MASTER, notify_master runs our failover shell script: ensure a secondary private IP, then associate the allocation.

Implementation sketch

Kernel: we often enable ip_forward / ip_nonlocal_bind where our HAProxy or nginx layout needs it. We validate per role, not globally.

Security groups: protocol 112 (Virtual Router Redundancy Protocol, VRRP) allowed between peers, not the open internet.

Keepalived: notify_master logs to a rotated file; credentials via an Identity and Access Management (IAM) instance profile where we can.

Instance identity: in production we fetch instance metadata using Instance Metadata Service version 2 (IMDSv2).

Example Keepalived skeleton (placeholders only, not a drop-in):

global_defs {
    enable_script_security
    script_user root
    vrrp_startup_delay 1
}

vrrp_script check_service {
    script "/usr/bin/systemctl is-active --quiet nginx"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    unicast_src_ip 10.0.0.10
    unicast_peer {
        10.0.0.11
    }
    virtual_router_id 51
    priority 200
    advert_int 1
    track_script {
        check_service
    }
    notify_master "/etc/keepalived/aws-failover.sh >> /var/log/keepalived/aws-failover.log"
}

Example failover script shape (replace IDs and IPs; use IMDSv2 in production):

#!/usr/bin/env bash
set -euo pipefail

ALLOCATION_ID="eipalloc-REPLACE_ME"
PRIVATE_IP_SECONDARY="10.0.0.50"
INTERFACE="eth0"

INSTANCE_ID="$(curl -sf http://169.254.169.254/latest/meta-data/instance-id)"

ip addr add "${PRIVATE_IP_SECONDARY}/32" dev "${INTERFACE}" || true

NI_ID="$(aws ec2 describe-instances \
  --instance-ids "${INSTANCE_ID}" \
  --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' \
  --output text)"

aws ec2 assign-private-ip-addresses \
  --network-interface-id "${NI_ID}" \
  --private-ip-addresses "${PRIVATE_IP_SECONDARY}"

aws ec2 associate-address \
  --allocation-id "${ALLOCATION_ID}" \
  --instance-id "${INSTANCE_ID}" \
  --private-ip-address "${PRIVATE_IP_SECONDARY}"

Tradeoffs of managing the edge ourselves

When we self-manage load balancer tiers instead of defaulting to AWS-managed front doors, we still need to evaluate the usual architectures: application or network load balancers, DNS failover, Kubernetes ingress, or the Elastic IP + Keepalived pattern this post describes.

Application Load Balancer (ALB)

Pros / cons (for anyone choosing ALB):

Upside: AWS-managed HA, health checks, Transport Layer Security (TLS) with AWS Certificate Manager (ACM), AWS Web Application Firewall (WAF), and a clear scaling story for HTTP.

Downside: cost at scale, less hands-on control over every packet and knob than raw EC2.

At All Quiet: we rely on managed load balancing for paths where we want AWS to own HA end-to-end, including customer-facing HTTP. We treat ALB-class tooling as the default when we do not want to operate the edge ourselves.

Network Load Balancer (NLB)

Pros / cons (for anyone choosing NLB):

Upside: TCP/UDP transparency, static IPs per Availability Zone (AZ), low listener overhead compared to full layer 7 (L7).

Downside: fewer HTTP-specific features than ALB; still another billable and operated AWS component.

At All Quiet: when we need AWS-managed HA but not full layer 7 (L7) termination at the edge, NLB-style fits better than ALB; we don’t replace every self-managed tier with NLB, but it’s on the same “managed edge” side of the spectrum as ALB.

DNS failover (Route 53)

Pros / cons (for anyone using DNS failover):

Upside: no instance-side EIP choreography; health-checked routing policies let AWS steer names.

Downside: DNS time to live (TTL) and caching stretch failover and failback; client stacks behave inconsistently; not a drop-in substitute for “one stable IP, instant swing.”

At All Quiet: DNS steering can complement other designs; we don’t rely on it alone when our mental model is exactly one Elastic IP jumping between two known EC2 nodes. That is what Keepalived plus the API covers.

Kubernetes / gateways (e.g. Amazon EKS)

Pros / cons (for anyone on Kubernetes):

Upside: HA via Services, Ingress / Gateway API, and cloud LB integration, which gives different primitives than a bare-metal pair.

Downside: cluster operational tax; not every workload belongs there.

At All Quiet: this article describes a pair pattern centered on virtual machines (VMs) because we still run meaningful tiers that way; where we use Amazon Elastic Kubernetes Service (EKS) or similar, ingress HA follows Kubernetes, not Keepalived on two fixed hosts.

Elastic IP + Keepalived + EC2 API (this post)

Pros / cons (for anyone building like this):

Upside: one stable public address in DNS; relatively few moving AWS objects; full control over timers and failover scripts.

Downside: you own IAM, idempotent scripts, logging, monitoring, and ambiguous states deserve runbooks and checks such as DescribeAddresses. Compared with a managed load balancer, cutover is not instantaneous on abrupt failure: traffic follows wherever the EIP is still associated until VRRP agrees on a new master, your health logic runs, and notify_master finishes calling AWS. The gap depends on advert_int, vrrp_script intervals, preempt settings, and API behavior. Those knobs trade sensitivity against stability; sub‑millisecond failover is not what this pattern promises.

At All Quiet: this is what we actually implemented for specific self-managed loadbalancer tiers: Ansible-deployed Keepalived, scripts on notify_master, AWS Cloud Development Kit (CDK) and infrastructure as code (IaC) for the EIP and IAM. That is the same stack this article walks through at a pattern level.

How we pick among them

Internally we ask: does this path’s service level objective (SLO) and budget justify a managed LB? Do we need layer 7 (L7) features only ALB gives us? Does scripted EIP failover fit this path’s resilience expectations (see the EIP downside above)? If not, we promote the tier (ALB/NLB or another design); we don’t stretch EIP+Keepalived past where it fits.

Takeaways

We run self-managed LBs in some slices of our infra; we needed explicit public HA there, and EIP + Keepalived + EC2 API is our compact answer.
VRRP decides who leads; AssociateAddress decides where the EIP points.
Managed ALB/NLB remain strong defaults when we want AWS to own HA at that layer.

Closing

We touch incident paths every day; when ingress misbehaves, people notice fast. If you operate similar edges, use this framing to decide when the pattern fits and when to promote that tier to managed load balancing instead.

Running our test environment fully on Nanos

Mads Quist — Thu, 18 Sep 2025 16:19:15 +0000

We've probably all had this dream of waking up in the morning and finding ourselves with 10,000 new users on our platform. (At least as a Co-Founder & CTO, that's the dream) 😁

So we asked ourselves: can we run a dedicated environment of our platform entirely on nanos?

Spoiler: it worked, and it taught us a lot about where our real inefficiencies were hiding.

Here are some of these learnings:

The Reality of Scaling:

When your startup does grow and you start scaling your infrastructure, what really happens? Often it turns out that:

Important indexes are missing, leading to CPU spikes.
Query results are loaded into memory without paging, causing out-of-memory errors.
Other inefficiencies appear that raw cloud scaling alone cannot solve.

The result is often not a sleek, hyper-scalable system but an extremely expensive piece of cloud infrastructure.

The best part about scaling: Downsizing

What's great about the cloud is not just that it scales up. It also lets you scale down.

Recently, we ran a load test we called nano testing. The idea was simple: take our infrastructure and run it on AWS EC2 nano instances. That is as small as it gets on AWS.

A nano instance has 512MB RAM and 2 virtual CPUs. That reminds me of my gaming PC from the year 2000. For comparison, your smartphone today probably has 10–20 times more RAM. We then dumped in about four times the amount of test data we normally process.

Can It Run on Nanos?

The fun begins when you try to make your platform run decently on nanos. It does not have to be blazing fast. The key question is: does it run at all?

If some API queries take a few seconds, or some asynchronous jobs and emails are processed with a bit of lag, that is perfectly fine. If your system can handle this, it means you have built something resilient.

Running on nanos lets you pinpoint weaknesses in your platform very clearly. Fixes are often low-hanging fruit:

Add batch processing here.
Add an index there.
Add throttling in another place.

Our Approach at All Quiet

At All Quiet, we now run a dedicated testing environment entirely on nanos. This allows us to observe scaling issues early and fix them before they turn into real problems.

Why We Built a MongoDB-Message Queue and Reinvented the Wheel

Mads Quist — Thu, 04 Jul 2024 04:33:19 +0000

Hey👋

I'm Mads Quist, founder of All Quiet . We've implemented a home-grown message queue based on MongoDB and I'm here to talk about:

Why we re-invented the wheel
How we re-invented the wheel

1. Why we re-invented the wheel

Why do we need message queuing?

All Quiet is a modern incident management platform, similar to PagerDuty. Our platform requires features like:

Sending a double-opt-in email asynchronously after a user registers
Sending a reminder email 24 hours after registration
Sending push notifications with Firebase Cloud Messaging (FCM), which can fail due to network or load problems. As push notifications are crucial to our app, we need to retry sending them if there's an issue.
Accepting emails from outside our integration and processing them into incidents. This process can fail, so we wanted to decouple it and process each email payload on a queue.

Our tech stack

To understand our specific requirements, it's important to get some insights into our tech stack:

We run a monolithic web application based on .NET Core 7. The .NET Core application runs in a Docker container.
We run multiple containers in parallel.
An HAProxy instance distributes HTTP requests equally to each container, ensuring a highly available setup.
We use MongoDB as our underlying database, replicated across availability zones.
All of the above components are hosted by AWS on generic EC2 VMs.

Why we re-invented the wheel

We desired a simple queuing mechanism that could run in multiple processes simultaneously while guaranteeing that each message was processed only once.
We didn't need a pub/sub pattern.
We didn't aim for a complex distributed system based on CQRS / event sourcing because, you know, the first rule of distributed systems is to not distribute.
We wanted to keep things as simple as possible, following the philosophy of choosing "boring technology".

Ultimately, it's about minimizing the number of moving parts in your infrastructure. We aim to build fantastic features for our excellent customers, and it's imperative to maintain our services reliably. Managing a single database system to achieve more than five nines of uptime is challenging enough. So why burden yourself with managing an additional HA RabbitMQ cluster?

Why not just use AWS SQS?

Yeah… cloud solutions like AWS SQS, Google Cloud Tasks, or Azure Queue Storage are fantastic! However, they would have resulted in vendor lock-in. We simply aspire to be independent and cost-effective while still providing a scalable service to our clients.

2. How we re-invented the wheel

What is a message queue?

A message queue is a system that stores messages. Producers of messages store these in the queue, which are later dequeued by consumers for processing. This is incredibly beneficial for decoupling components, especially when processing messages is a resource-intensive task.

What characteristics should our queue show?

Utilizing MongoDB as our data storage
Guaranteeing that each message is consumed only once
Allowing multiple consumers to process messages simultaneously
Ensuring that if message processing fails, retries are possible
Enabling scheduling of message consumption for the future
Not needing guaranteed ordering
Ensuring high availability
Ensuring messages and their states are durable and can withstand restarts or extended downtimes

MongoDB has significantly evolved over the years and can meet the criteria listed above.

Implementation

In the sections that follow, I'll guide you through the MongoDB-specific implementation of our message queue. While you'll need a client library suitable for your preferred programming language, such as NodeJS, Go, or C# in the case of All Quiet, the concepts I'll share are platform agnostic.

Queues

Each queue you want to utilize is represented as a dedicated collection in your MongoDB database.
Message Model

Here's an example of a processed message:

{
    "_id" : NumberLong(638269014234217933),
    "Statuses" : [
        {
            "Status" : "Processed",
            "Timestamp" : ISODate("2023-08-06T06:50:23.753+0000"),
            "NextReevaluation" : null
        },
        {
            "Status" : "Processing",
            "Timestamp" : ISODate("2023-08-06T06:50:23.572+0000"),
            "NextReevaluation" : null
        },
        {
            "Status" : "Enqueued",
            "Timestamp" : ISODate("2023-08-06T06:50:23.421+0000"),
            "NextReevaluation" : null
        }
    ],
    "Payload" : {
        "YourData" : "abc123"
    }
}

Let’s look at each property of the message.

_id

The _id field is the canonical unique identifier property of MongoDB. Here, it contains a NumberLong, not an ObjectId . We need NumberLong instead of ObjectId because:

While ObjectId values should increase over time, they are not necessarily monotonic. This is because they:

Only contain one second of temporal resolution, so ObjectId values created within the same second do not have a guaranteed ordering, and are generated by clients, which may have differing system clocks.

In our C# implementation, we generate an Id with millisecond precision and guaranteed ordering based on insertion time. Although we don't require strict processing order in a multi-consumer environment (similar to RabbitMQ), it's essential to maintain FIFO order when operating with just one consumer. Achieving this with ObjectId is not feasible. If this isn't crucial for you, you can still use ObjectId.

Statuses

The Statuses property consists of an array containing the message processing history. At index 0, you'll find the current status, which is crucial for indexing.

The status object itself contains three properties:

Status: Can be "Enqueued", "Processing", "Processed", or "Failed".
Timestamp: This captures the current timestamp.
NextReevaluation: Records when the next evaluation should occur, which is essential for both retries and future scheduled executions.

Payload

This property contains the specific payload of your message.

Enqueuing a message

Adding a message is a straightforward insert operation into the collection with the status set to "Enqueued".

For immediate processing, set NextReevaluation to null.
For future processing, set NextReevaluation to a timestamp in the future, when you want your message to be processed.

db.yourQueueCollection.insert({
    "_id" : NumberLong(638269014234217933),
    "Statuses" : [
        {
            "Status" : "Enqueued",
            "Timestamp" : ISODate("2023-08-06T06:50:23.421+0000"),
            "NextReevaluation" : null
        }
    ],
    "Payload" : {
        "YourData" : "abc123"
    }
});

Dequeuing a message

Dequeuing is slightly more complex but still relatively straightforward. It heavily relies on the concurrent atomic read and update capabilities of MongoDB.

This essential feature of MongoDB ensures:

Each message is processed only once.
Multiple consumers can safely process messages simultaneously.

db.yourQueueCollection.findAndModify({
   "query": {
      "$and": [
         {
            "Statuses.0.Status": "Enqueued"
         },
         {
            "Statuses.0.NextReevaluation": null
         }
      ]
   },
   "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Processing",
                  "Timestamp": ISODate("2023-08-06T06:50:23.800+0000"),
                  "NextReevaluation": null
               }
            ],
            "$position": 0
         }
      }
   }
});

So we are reading one message that is in state “Enqueued” and at the same time modify it by setting the status “Processing” at position 0. Since this operation is atomic it will guarantee that the message will not be picked up by another consumer.

Marking a message as processed

Once the processing of the message is complete, it's a simple matter of updating the message status to "Processed" using the message’s id.

db.yourQueueCollection.findAndModify({
   "query": {
     "_id": NumberLong(638269014234217933)
   },
   "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Processed",
                  "Timestamp": ISODate("2023-08-06T06:50:24.100+0000"),
                  "NextReevaluation": null
               }
            ],
            "$position": 0
         }
      }
   }
});

Marking a message as failed

If processing fails, we need to mark the message accordingly. Often, you might want to retry processing the message. This can be achieved by re-enqueuing the message. In many scenarios, it makes sense to reprocess the message after a specific delay, such as 10 seconds, depending on the nature of the processing failure.

db.yourQueueCollection.findAndModify({
   "query": {
     "_id": NumberLong(638269014234217933)
   },
   "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Failed",
                  "Timestamp": ISODate("2023-08-06T06:50:24.100+0000"),
                  "NextReevaluation": ISODate("2023-08-06T07:00:24.100+0000")
               }
            ],
            "$position": 0
         }
      }
   }
});

The dequeuing loop

We've established how we can easily enqueue and dequeue items from our "queue," which is, in fact, simply a MongoDB collection. We can even "schedule" messages for the future by leveraging the NextReevaluation field.

What's missing is how we will dequeue regularly. Consumers need to execute the findAndModify command in some kind of loop. A straightforward approach would be to create an endless loop in which we dequeue and process a message. This method is straightforward and effective. However, it will exert considerable pressure on the database and the network.

An alternative would be to introduce a delay, e.g., 100ms, between loop iterations. This will significantly reduce the load but will also decrease the speed of dequeuing.

The solution to the problem is what MongoDB refers to as a change stream.

MongoDB Change Streams

What are change streams? I can’t explain it better than the guys at MongoDB:

Change streams allow applications to access real-time data changes […]. Applications can use change streams to subscribe to all data changes on a single collection […] and immediately react to them.

Great! What we can do is listen to newly created documents in our queue collection, which effectively means listening to newly enqueued messages

This is dead simple:

const changeStream = db.yourQueueCollection.watch();
changeStream.on('insert', changeEvent => {
  // Dequeue the message
  db.yourQueueCollection.findAndModify({
    "query": changeEvent.documentKey._id,
    "update": {
      "$push": {
         "Statuses": {
            "$each": [
               {
                  "Status": "Processing",
                  "Timestamp": ISODate("2023-08-06T06:50:24.100+0000"),
                  "NextReevaluation": null
               }
            ],
            "$position": 0
         }
      }
   }
});

Scheduled and Orphaned Messages

The change stream approach, however, does not work for both scheduled and orphaned messages because there is obviously no change that we can listen to.

Scheduled messages simply sit in the collection with the status "Enqueued" and a "NextReevaluation" field set to the future.
Orphaned messages are those that were in the "Processing" status when their consumer process died. They remain in the collection with the status "Processing" but no consumer will ever change their status to "Processed" or "Failed".

For these use cases, we need to revert to our simple loop. However, we can use a rather generous delay between iterations.

Wrapping it up

"Traditional" databases, like MySQL, PostgreSQL, or MongoDB (which I also view as traditional), are incredibly powerful today. If used correctly (ensure your indexes are optimized!), they are swift, scale impressively, and are cost-effective on traditional hosting platforms.

Many use cases can be addressed using just a database and your preferred programming language. It's not always necessary to have the "right tool for the right job," meaning maintaining a diverse set of tools like Redis, Elasticsearch, RabbitMQ, etc. Often, the maintenance overhead isn't worth it.

While the solution proposed might not match the performance of, for instance, RabbitMQ, it's usually sufficient and can scale to a point that would mark significant success for your startup.

Software engineering is about navigating trade-offs. Choose yours wisely.

DEV Community: Mads Quist

Why We Built Live Call Routing the Lean Way

Why We Built Live Call Routing the Lean Way

The "contact sales for pricing" wall

Why we chose Bring Your Own Provider (BYOP)

SRE-first design: UI-friendly, Terraform-ready

1. IVRs should not require a certification

2. Infrastructure as Code (yes, even for your phone tree)

Available for everyone, not just enterprise

On-Call is the daily business; Incident Management is a Philosophy

If Your On-Call Strategy is Just "Make it Louder," We Need to Talk.

Why does philosophy matter for SRE or DevOps leaders?

Scenario A: Alert fatigue

Scenario B: The needle-in-a-haystack

The real issue

"I need an alert" vs "I need a system"

Surface-level fix

Structural fix

How All Quiet helps teams build chaos-free philosophies

Noise reduction that actually works

Built-in learning

Routing based on actual knowledge

Communication that builds trust

The result: a team that doesn't fear the pager

Infrastructure as Code (IaC) is Not an Add-On

If It's Not in Git, It Doesn't Exist: Why IaC Isn't An Add-On for Incident Management Platforms

What is Infrastructure as Code (IaC)?

The real problem with manual rotations

Configuration drift

Human error

Zero visibility

Multi-team complexity

Terraform 101 (explained like you're a smart engineer who just wants the short version)

All Quiet + Terraform: A match made in DevOps heaven

No more mystery changes

Centralized control

Consistency across teams

Predictability

What IaC unlocks for incident management

Predictability

Auditability

Reproducibility

Governance without bureaucracy

Less cognitive load

An example of managing on-call via code

The cultural shift to IaC as a first-class citizen

The future is declarative (and much less painful)

Top Opsgenie Alternatives and Migration Targets: How to Transition in 2026

Quick Answer: Opsgenie End of Life (EOL) Facts

Opsgenie Migration Timeline: Key Dates

Top Opsgenie Alternatives for 2026

What to Look For When Replacing Opsgenie

Deep Dive: The Best Opsgenie Alternatives

All Quiet: The Modern Choice for Lean Teams

Opsgenie Migration Resources

Jira Service Management: The Official Path

PagerDuty: The Enterprise Standard

Specialized Coordination: Rootly and incident.io

Practical Opsgenie Migration Checklist

Final Thoughts

Top Incident Management Solutions: Best Incident Management Software in 2026

Modern teams aren't struggling because they lack data, but because they're drowning in it. Here's how the top incident management tools in 2026 stack up.

The Old Guard vs the New Wave

At a Glance

The New Wave of Incident Management Tools

Lean, integrated and modern

Pros vs Cons

Integrated Workflows

Lower Cost of Ownership

Pricing

Ideal for Small and Mid-Sized Teams

The Old Guard

Powerful but heavyweight

PagerDuty: The Enterprise Standard That's Overkill for Smaller Teams

Pricing

Who It's Best For

Opsgenie: Great Inside Atlassian but Not Much Else (Plus Deprecation in 2027)

Pros vs Cons

Pricing

Lock-In Issues