Site Reliability

Enable service-managed failover for Cosmos DB

One capability across every multi-region Cosmos DB account: make sure that when the primary write region goes dark, Azure promotes a secondary region's write region for you, automatically, instead of leaving your application stuck waiting for a human to react.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Service-managed failover: the basics

What actually happens to a multi-region Cosmos DB account when its write region fails?

A Cosmos DB account that replicates to more than one region still has exactly one write region at a time when it is configured for single-region writes. Every insert, update and delete goes to that one region; the other regions serve reads from a replicated copy. This is a perfectly reasonable, lower-cost topology, and most production accounts run it. The catch is what happens when the write region has an outage. The read regions keep serving reads, but writes stop, because there is nowhere to send them, until the write region comes back or someone promotes a different region to take over.

Azure Advisor surfaces this gap as a reliability recommendation: 'Enable service managed failover for Cosmos DB account.' With service-managed failover turned on, Azure detects a primary region outage and promotes the next region in your failover-priority list to be the new write region, with no user action required. Writes resume against the new region automatically. With it turned off, a write-region outage means your application's writes are down until an operator notices, decides to fail over, and runs the promotion by hand, which is exactly the moment you least want to depend on someone being awake and confident.

Most accounts that lack this are not lacking it on purpose. An account gets a second region added for read latency or compliance, and the failover behaviour is simply left at its default. The work is to find every multi-region, single-write account in the estate, confirm its failover-priority order is the one you would actually want to promote, and switch service-managed failover on so the promotion happens for you rather than at three in the morning under pressure.

In this lesson you will learn how Cosmos DB expresses write-region failover, why a multi-region account on manual failover still has a single point of write failure, how to find every account in this state across a subscription, and how to switch them to service-managed failover safely after confirming the failover-priority order. The Advisor recommendation behind it is 'Enable service managed failover for Cosmos DB account', and the fix is a single command per account at no extra Azure cost.

Fun fact

The replica that could not rescue the write

Large regional cloud outages have a recurring pattern in the postmortems: teams discover that the expensive standby they were paying for did not take over on its own. The replica was healthy, the data was there, but the topology was configured to wait for a human decision, so writes stayed down until an operator stepped in. Cosmos DB's service-managed failover exists precisely to remove that human-in-the-loop decision for single-write accounts. Microsoft is explicit, though, that it is not instantaneous: declaring the outage and triggering service-managed failover can itself take significant time, potentially an hour or more, even for a full write-region outage. That is why Microsoft recommends a forced failover as the fast path when you need to restore writes quickly, and why you want the failover-priority order armed in advance rather than worked out during the event.

Finding accounts that cannot fail over on their own

Priya is the platform reliability lead at a payments company that runs several Cosmos DB accounts, most of them replicated to a second region for read latency and regional compliance. Azure Advisor has raised 'Enable service managed failover for Cosmos DB account' against three of them.

Rather than click through each recommendation, Priya starts by listing which accounts have more than one region but still have automatic failover switched off, so she can see exactly where the company is paying for a second region without getting the availability it should buy.

Start by listing every account, how many regions it spans, and whether automatic failover is on. The dangerous accounts are multi-region with failover off.

$ az cosmosdb list --query "[].{name:name, rg:resourceGroup, regions:length(locations), autoFailover:enableAutomaticFailover}" -o table

Name Rg Regions AutoFailover

---------------- ------------ --------- --------------

payments-prod payments-rg 2 False

ledger-prod payments-rg 2 False

analytics-read data-rg 1 False

# payments-prod and ledger-prod span 2 regions but will not fail over on their own.

# analytics-read is single-region, so failover does not apply to it.

A multi-region account with automatic failover off is paying for resilience it cannot use without a human. A single-region account is a different problem, and is not what this recommendation is about.

How Cosmos DB decides a write region and how failover changes thatdeep dive

A Cosmos DB account configured for single-region writes keeps an ordered failover-priority list of its regions. The region at priority 0 is the current write region; the rest are read regions ranked by the order in which they should be promoted. The 'enableAutomaticFailover' property on the account governs what happens when the priority-0 region becomes unavailable. When it is false, nothing promotes on its own: a human must trigger a failover, which reorders the priority list and moves writes to a new region. When it is true, Azure performs that promotion for you, moving writes to the next region in the priority order with no user action.

Two details matter when you arm this. First, service-managed failover only applies to accounts with a single write region; an account configured for multi-region writes already accepts writes in every region and does not need it. Second, automatic failover honours the failover-priority order you have set, so the order is not a formality: it is the actual decision about which region your application runs in after an outage. Confirm it before you enable, because enabling automatic failover is also accepting that order as your recovery plan.

Microsoft is clear about the limits. Service-managed failover promotes a secondary on its own, but Microsoft documents that declaring the outage and triggering the failover can take significant time, potentially an hour or more, and this applies to a full write-region outage, not just an edge case. For faster recovery Microsoft recommends performing a forced failover yourself rather than waiting for the service to trigger. Service-managed failover is therefore not a promise of instant recovery; it removes the need for a human to decide and run the promotion, but the detection-and-trigger latency still sits with Microsoft. For partial-region resilience Cosmos DB offers per-partition automatic failover (PPAF), which fails over individual partitions to a secondary and recovers far faster than a whole-account failover. Service-managed failover also pairs naturally with zone redundancy within each region, which protects against a single datacentre failing without needing a cross-region failover at all.

What is the impact of leaving failover on manual?

The direct impact is write downtime measured in human reaction time. When the write region of a manual-failover account fails, reads may continue from the secondary, but every write fails until an operator notices the outage, decides to fail over, and performs the promotion. During a large regional event, that is the worst possible moment to depend on a person: alerts are noisy, the on-call engineer may be one of many teams scrambling, and the decision to fail over a production database carries its own hesitation. Minutes become hours, and every one of them is writes your application cannot accept.

The second-order impact is that the cost of the resilience is already being paid without the benefit being collected. A multi-region account is charged for the throughput and storage of every region it replicates to. If failover is manual, you are paying the full price of running in two regions and getting only the read-latency half of what that buys. The availability half, the reason multi-region exists, sits switched off until someone turns it on by hand under pressure.

On the reliability side, Azure Advisor raises this precisely because a single-write, multi-region account with manual failover has a single point of write failure that the account's own topology is already equipped to remove. Enabling service-managed failover is the cheapest, most defensible step you can take to close that gap, and it is the kind of recommendation that reads badly in a postmortem if it was open at the time of an outage.

How do you arm automatic failover safely?

Work this as one capability across the estate rather than clicking individual recommendations. The order matters: confirm the failover-priority order before you enable automatic failover, because enabling it is accepting that order as your recovery plan.

1. Inventory multi-region, single-write accounts

List every Cosmos DB account, how many regions it spans, and whether automatic failover is on. The accounts that matter are those with two or more regions and 'enableAutomaticFailover' set to false. A single-region account is a different conversation: it needs a second region added before failover means anything.

2. Confirm the failover-priority order on each

For each multi-region account, check the failover-priority list and decide whether the region at priority 1 is genuinely where you want writes to land after an outage, given latency, data residency and capacity. This order is your recovery plan, not a formality. Fix it before enabling automatic failover, so the automatic promotion goes where you intend.

3. Enable service-managed failover

Switch automatic failover on for each confirmed account. The change is a single command and takes effect without downtime: it does not move the write region, it only arms the account to promote the secondary on its own if the primary fails. Prioritise the accounts whose write outages cost the most: revenue paths and systems of record first.

4. Standardise it in your infrastructure code

Set 'enableAutomaticFailover: true' in the Bicep or template module that provisions Cosmos DB accounts, alongside an explicit failover-priority order and zone redundancy where the region supports it, so every new multi-region account is born with automatic failover armed rather than discovered missing on the next Advisor report.

# Arm service-managed failover on a confirmed multi-region account.
# This does NOT move the write region; it only enables automatic promotion.
az cosmosdb update \
  --name payments-prod \
  --resource-group payments-rg \
  --enable-automatic-failover true

# Confirm (or set) the failover-priority order: priority 0 is the write region,
# the rest are promoted in ascending order. This order IS your recovery plan.
az cosmosdb failover-priority-change \
  --name payments-prod \
  --resource-group payments-rg \
  --failover-policies 'North Europe=0' 'West Europe=1'

# --- Standardise it in Bicep so new accounts are born armed ---
# resource cosmos 'Microsoft.DocumentDB/databaseAccounts@2024-11-15' = {
#   name: accountName
#   location: primaryRegion
#   properties: {
#     databaseAccountOfferType: 'Standard'
#     enableAutomaticFailover: true
#     locations: [
#       { locationName: 'North Europe', failoverPriority: 0, isZoneRedundant: true }
#       { locationName: 'West Europe',  failoverPriority: 1, isZoneRedundant: true }
#     ]
#   }
# }

Quick quiz

Question 1 of 5

Azure Advisor raises 'Enable service managed failover for Cosmos DB account' against a two-region account configured for single-region writes. What does this recommendation actually change?

Keep learning

Go deeper on how Cosmos DB expresses failover, high availability and zone redundancy across the settings in this capability.

You can now treat write-region failover as one capability rather than a scatter of Advisor findings: inventory every multi-region, single-write account, confirm the failover-priority order is the recovery plan you actually want, arm service-managed failover so the secondary promotes itself, and standardise it in your infrastructure code so new accounts are born armed. The fix is a single command per account and adds nothing to the bill you are already paying for the second region.

Back to the library

Service-managed failover: the downtime and cost view

A no-extra-charge setting that converts an hours-long write outage into an automatic recovery

Service-managed failover does not add to your Cosmos DB bill. You are already paying for the second region the moment you replicate to it: that is where the cost of resilience sits, and it is a decision you have already taken. Turning service-managed failover on simply makes the region you are already paying for actually take over when the primary fails, instead of sitting there as an expensive read replica that cannot rescue your writes without a human.

Frame the recommendation as the difference between paying for resilience and getting it. The expensive part, the second region, is already on the bill. The cheap part, flipping failover to automatic, is what turns that spend into protection. An account left on manual failover is paying the full price of multi-region and capturing only the read-latency benefit, not the availability one.

The arithmetic is one-sided. The cost of enabling it is zero incremental Azure spend and a few minutes of change control. The cost of leaving it off is measured in the length of a write outage multiplied by what an hour of stopped writes does to revenue, abandoned transactions, SLA credits owed to your own customers, and the engineering and on-call time spent recovering by hand under pressure.

This lesson is for the finance partner who sees a Cosmos DB reliability recommendation on the Advisor report and wants to know what it costs and what it buys. It covers why the expensive part, the second region, is already on the bill, why flipping failover to automatic costs nothing extra, and how to value the avoided downtime so the recommendation reads as collecting protection you have already paid for.

Fun fact

The replica that could not rescue the write

How a finance partner frames the failover decision

Priya is the finance partner supporting the payments platform. The Advisor report flags three Cosmos DB accounts for service-managed failover, and the instinct is to ask what enabling it will add to the bill. The answer is nothing: the second region on each of these accounts is already provisioned and already being charged for, every month, whether or not it can take over writes. The spend decision, the expensive one, was made when the second region was added. What is on the table now is free.

Priya asks the team to put a number on the other side instead: what an hour of stopped writes costs this business. For the payments account, writes down means transactions failing at the point of sale, customers retrying or walking away, and SLA credits owed to merchants. For the ledger account, writes down means settlement falling behind. The finance pack reframes the recommendation cleanly: 'We are already paying for the standby region on all three accounts. Service-managed failover adds nothing to the bill and converts a write outage that today depends on someone reacting by hand into an automatic recovery. The only question is whether we want the protection we are already buying.'

Why manual failover belongs on the downtime-cost ledger

The cost model here is unusually clean. The expensive resource, the second region, is already provisioned and already on the bill. Enabling service-managed failover adds nothing. So the trade is not cost-against-cost; it is zero incremental spend against the avoided cost of a write outage. The only honest way to weigh it is to put a figure on what an hour of stopped writes does to this specific business: lost or failed transactions, customers who do not retry, SLA credits owed to your own customers, and the on-call and engineering hours burned recovering by hand.

Those outage costs are real and, during a regional event, can dwarf an entire month of the account's run rate. Against them, the remediation is a few minutes of change control to flip a setting you are already entitled to. The finance role is to make sure the second region's cost is recognised as buying availability, not just read latency, and that the recommendation is read as collecting protection already purchased rather than as a new line of spend.

What finance can do about the failover gap

Finance cannot flip a database setting, but it owns the framing that turns a reliability recommendation into a decision about collecting protection already paid for. Three levers.

1. Recognise the second region as buying availability, not just latency

Make explicit that the second region on each flagged account is already on the bill and already charged in full every month. Enabling service-managed failover adds nothing to that. The framing that matters is that the spend on the replica is only half-used while failover is manual: it buys read latency but not the automatic availability it is capable of. Flipping failover to automatic is how you collect the half you are already paying for.

2. Put a number on an hour of stopped writes

Ask the team to estimate, per account, what one hour of failed writes costs: lost or failed transactions, customer churn, SLA credits owed to your customers, and on-call and engineering hours. That figure is the entire value of the recommendation, because the remediation itself is free. Order the accounts by that cost, so the revenue paths and systems of record are armed first, not whichever the report happens to list first.

3. Require failover to be automatic on every account you pay to replicate

Set the expectation in the cost-and-resilience review that any account funded for a second region must also have service-managed failover armed, on the record. Paying for a standby that cannot take over without a human is the worst of both worlds: the full cost of multi-region with only the read-latency benefit. The finance-visible rule is simple: if we are funding the replica, we collect the availability.

Quick quiz

Question 1 of 5

Advisor flags three multi-region Cosmos DB accounts for service-managed failover. As the finance partner, what should you expect enabling it to add to the Azure bill?

Keep learning

Go deeper on how Cosmos DB expresses failover, high availability and zone redundancy across the settings in this capability.

You have finished the finance view of service-managed failover. You know the cost model is one-sided: the expensive part, the second region, is already on the bill, and arming automatic failover adds nothing while converting an hours-long write outage into an automatic recovery. Next time a Cosmos DB reliability recommendation lands, you will value it by the cost of an hour of stopped writes, order the accounts by that figure, and treat any funded replica without automatic failover as protection you are paying for but not collecting.

Back to the library

Service-managed failover: the headline

Whether a regional outage costs you minutes of automatic recovery or hours of manual scramble

When a cloud region has a bad day, the question leadership ends up asking is simple: did our application keep working, and if not, how long was it down and why? For a Cosmos DB account on manual failover, the honest answer is that writes were down for as long as it took a person to notice the outage, decide to fail over, and do it by hand. That is an availability gap that depends on human reaction time during the worst possible window.

The leadership question is not 'are we multi-region?' Most teams already are, and already paying for it. It is 'when the primary region fails, does recovery happen automatically, or does it wait for someone to react?' The defensible end state is that every account you are already paying to replicate also fails over on its own, so a regional outage is an automatic blip rather than a manual incident.

This is not a budget decision. The expensive choice, running in more than one region, has already been made and is already on the bill. What remains is a governance decision about whether you actually collect the availability you are paying for, or leave it switched off and hope nobody has to fail over by hand on a bad night.

A short read for the leader who needs to know what an account on manual failover actually risks during a regional outage, why making failover automatic is a governance decision rather than a budget one, and what a defensible end state looks like across every multi-region database in the estate.

Fun fact

The replica that could not rescue the write

What it looks like when recovery is automatic, not manual

After a regional cloud outage took a competitor's checkout offline for several hours and made the trade press, the CEO asked the obvious question at the next operations review: if that region had been ours, how long would we have been down? The honest answer at the time was uncomfortable. The payments database was replicated to a second region, so the data was safe, but failover was set to manual. Writes would have stayed down until the on-call engineer confirmed the outage, decided to promote the secondary, and ran the failover by hand, however long that took on a bad night.

The team's response was to stop treating failover as something to perform during an incident and start treating it as something armed before one. They listed every multi-region account, confirmed the failover-priority order on each so the promotion would land in the region they actually wanted, and switched service-managed failover on across all of them. The next time the CEO asked the question, the answer had changed from 'it depends how fast someone reacts' to 'the write region promotes itself automatically, and we have already chosen which region it promotes to.' That shift, from depending on human reaction time during the worst window to having the recovery armed in advance, is the confidence signal this capability delivers, and it costs nothing on top of the regions already on the bill.

Why this is a board-level resilience question

Almost every painful regional-outage story has the same shape: the standby was there, the data was safe, and the service still went down because failover waited on a human to decide. Service-managed failover removes the need for someone to notice, decide and run the promotion by hand for the databases you are already paying to replicate. It does not promise instant recovery: Microsoft documents that the service can take an hour or more to declare an outage and trigger the failover, and it recommends a forced failover as the fast path when writes must come back quickly. What you gain is that the recovery path is armed and the failover order chosen in advance, rather than worked out under pressure on a bad night.

The cost of getting this wrong is the length of an outage multiplied by what your business loses per hour of stopped writes, and that is a number that lands on the board after an incident. The cost of getting it right is essentially nothing on top of the regions already on the bill. This is the rare reliability control where the risk of inaction is severe and the cost of action is zero incremental spend, which is exactly the trade leadership should be quickest to approve.

The leadership move on failover

The executive handle is not to approve each setting individually; it is to require that every database the company already pays to replicate also recovers automatically, with the failover order chosen in advance and on the record.

1. Set a deadline to arm the estate

Ask for a date by which every multi-region, single-write Cosmos DB account has its failover-priority order confirmed and service-managed failover enabled, and by which the infrastructure-as-code module sets it by default so new accounts are born armed. The difference between an outage that self-recovers and one that waits on a human should be a closed item with a date, not an open Advisor recommendation.

2. Ask for the recovery plan, not just the toggle

Enabling automatic failover is accepting a specific order of regions as the recovery plan. Ask to see, for each critical account, which region writes promote to after an outage and why, given latency, data residency and capacity. The proof that this is handled is a named failover order per account, not a verbal 'failover is on.'

3. Treat single-region critical accounts as a separate decision

Service-managed failover only helps accounts that already have a second region. Any business-critical account still running in a single region is a different and more expensive decision: adding a region first. Keep that distinction explicit so the cheap win, arming failover on accounts already replicated, is not confused with the funded decision to make a single-region system multi-region.

Quick quiz

Question 1 of 5

At an operations review you ask how long the company would have been down if a competitor's recent regional outage had hit your estate. For a Cosmos DB account on manual failover, what is the honest answer?

Keep learning

Go deeper on how Cosmos DB expresses failover, high availability and zone redundancy across the settings in this capability.

Two takeaways. Service-managed failover is the rare reliability control where the risk of inaction, an hours-long write outage during a regional event, is severe and the cost of action is zero incremental spend on top of regions already on the bill, so it is the trade you should be quickest to approve. And the defensible end state is not 'we are multi-region'; it is that every account you already pay to replicate also recovers on its own, with the failover-priority order chosen in advance and on the record.

Back to the library

Part of the learning path Build in Azure resilience

Enable service-managed failover for Cosmos DB

Service-managed failover: the basics

The replica that could not rescue the write

Finding accounts that cannot fail over on their own

How Cosmos DB decides a write region and how failover changes thatdeep dive

What is the impact of leaving failover on manual?

How do you arm automatic failover safely?

1. Inventory multi-region, single-write accounts

2. Confirm the failover-priority order on each

3. Enable service-managed failover

4. Standardise it in your infrastructure code

Quick quiz

Keep learning

Service-managed failover: the downtime and cost view

The replica that could not rescue the write

How a finance partner frames the failover decision

Why manual failover belongs on the downtime-cost ledger

What finance can do about the failover gap

1. Recognise the second region as buying availability, not just latency

2. Put a number on an hour of stopped writes

3. Require failover to be automatic on every account you pay to replicate

Quick quiz

Keep learning

Service-managed failover: the headline

The replica that could not rescue the write

What it looks like when recovery is automatic, not manual

Why this is a board-level resilience question

The leadership move on failover

1. Set a deadline to arm the estate

2. Ask for the recovery plan, not just the toggle

3. Treat single-region critical accounts as a separate decision

Quick quiz

Keep learning

Related site reliability lessons