# Do not schedule a full Service Fabric shutdown around ephemeral cluster state

> Why can stopping every Service Fabric node make a later restart unrecoverable?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-179-do-not-schedule-a-full-service-fabric-shutdown-around-ephemeral-cluster-state/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:28:57+00:00
- Modified: 2026-09-10T00:55:36+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

Why can stopping every Service Fabric node make a later restart unrecoverable?

## Potentially affected

Service Fabric clusters storing state on local ephemeral disks.

## DSE recommendation

DSE recommends excluding these stateful clusters from blanket all-node shutdown schedules.

## Article

## Source facts

Microsoft warns against routinely stopping every node in a Service Fabric cluster whose state resides on local ephemeral disks. If a VM returns on another host, its local state does not follow it. A replacement node normally catches up from other nodes, but stopping them all can leave too many restarted nodes without the state needed to recover the cluster. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-common-questions).

## Applicability

Check the actual state location and shutdown scope before applying a VM scheduling rule. This question is about losing the cluster’s surviving state copies together, not whether an individual guest can perform an orderly operating-system shutdown. Do not infer recoverability from a list of powered-off VM resources.

## DSE recommendation

DSE recommends excluding these stateful clusters from blanket all-node shutdown schedules. Have the cluster owner review the proposed operating model and documented maintenance path. For disposable application testing, consider the source’s approach of creating test clusters through the delivery pipeline instead of relying on a stopped cluster to retain state. Keep any retained application data and recovery requirements explicit.

## Verification

Review the scheduler’s target inventory and confirm that the exception covers every relevant node type. Rehearse replacement and recovery only in a disposable cluster with appropriate test data. Validate the application’s state after reconstruction and retain the result. Do not test the warning by stopping an entire production cluster, and do not report an untested restart plan as a recovery capability.

## Official references

[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-common-questions). Source retrieved September 9, 2026.

## Primary reference

- Name: Common questions about Microsoft Azure Service Fabric - Azure Service Fabric | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-common-questions
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not schedule a full Service Fabric shutdown around ephemeral cluster state,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-179-do-not-schedule-a-full-service-fabric-shutdown-around-ephemeral-cluster-state/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.