# Interpret Service Fabric replication-queue warnings by replica role

> Where should investigation begin when a Service Fabric replication queue is full on the primary versus a secondary?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:23:32+00:00
- Modified: 2026-09-10T02:11:17+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

Where should investigation begin when a Service Fabric replication queue is full on the primary versus a secondary?

## Potentially affected

Service Fabric replicas reporting PrimaryReplicationQueueStatus or SecondaryReplicationQueueStatus.

## DSE recommendation

DSE recommends preserving the reporting replica's role before assigning a queue warning to a storage or network owner.

## Article

## Source facts

Service Fabric reports a full replication queue through System.Replicator. On a primary, the usual cause is slow acknowledgement by a secondary; on a secondary, it is usually slow application of operations. The warning clears when the queue is no longer full. The documented investigation starts with inter-node connectivity for a primary warning, but disk usage and performance on the reporting node for a secondary warning. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports).

## Applicability

Use the report’s property and replica role to identify which branch applies. These are documented common causes, not a conclusive diagnosis of a particular machine. Avoid interpreting every queue warning as evidence that the reporting node’s own disk is the bottleneck.

## DSE recommendation

DSE recommends preserving the reporting replica’s role before assigning a queue warning to a storage or network owner. For a primary report, review connectivity and then investigate slow secondary acknowledgement. For a secondary report, start with its disk observations and examine its connection back to the primary. Keep the participating replica and node identities attached to the evidence so the two perspectives are not mixed.

## Verification

Compare the warning interval with relevant connection and disk observations during an approved investigation. Record whether the queue warning clears after the identified cause is corrected, while separately testing the application’s expected operation. If the measurements do not support the common cause, retain that mismatch and continue diagnosis rather than labeling a component failed solely from the queue property.

## Official references

[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports). Source retrieved September 9, 2026.

## Primary reference

- Name: Troubleshoot with system health reports - Azure Service Fabric | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Interpret Service Fabric replication-queue warnings by replica role,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/
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.