Why Logic Apps run history is showing failure, while the message is processed successfully?

Question

Why Logic Apps run history is showing failure, while the message is processed successfully?

Karthik K Koneru 81

I have a Logic apps workflow where a failed event message is written on to DLQ Error queue to re-process later.
Sometimes logic apps RunHistory shows these messages were failed with "BadRequest" Error message with status as "Failed". But actually the message was written successfully on to DLQ. See below screen shots. User's image

User's image

DLQ Message Properties:
User's image

Wanted to understand why it is happening like this.

Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-03-28T00:14:43.1066667+00:00

Hi @Karthik K Koneru , following up to see if the above provided information is helpful. Please let me know if you have any questions.
Karthik K Koneru 81 Reputation points

2026-03-31T13:40:52.0633333+00:00

Thank you for the detailed explanation — that clarified why the Logic App run is marked Failed even though the message ends up in the DLQ. That part makes sense now.

I have a follow‑up question regarding DLQ reprocessing behavior, specifically for messages that were automatically dead‑lettered by Service Bus with (deadLetterReason = MaxDeliveryCountExceeded)
Messages are dead‑lettered in two ways:
Automatically by Service Bus when max delivery count is exceeded.
Manually by Logic Apps when a downstream API call fails

We have a secondary Logic App workflow that runs once daily to:

Read messages from the DLQ and Re‑enqueue them to the main queue for reprocessing.
Messages that were manually dead‑lettered are consistently picked up by the DLQ reprocessing workflow.However, messages with (deadLetterReason = MaxDeliveryCountExceeded) are sometimes not picked up on the first run of the DLQ reprocessing workflow.If I re‑run the same workflow, those messages are then picked up and processed.
Is there any known or expected behavior where automatically dead‑lettered messages (MaxDeliveryCountExceeded) are not processed on the first run?
I’d appreciate any guidance or best practices. Thanks in advance for the help!
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-01T01:15:30.6366667+00:00
@Karthik K Koneru This isn't a bug in Logic Apps or Service Bus, but a side-effect of how the Service Bus DLQ trigger polls and how “automatic” dead-lettering happens under the covers:

Automatic dead-letter (MaxDeliveryCountExceeded) happens entirely in the broker and then the message shows up in the DLQ.

The Logic App Service Bus DLQ trigger is a polling trigger (peek-lock style), so there can be a small delay from the time the broker moves the message to DLQ and when that message becomes visible to your trigger.

If your daily DLQ-reprocessing runs immediately after a batch of messages auto-dead-letter, some messages might not yet be surfaced when the trigger polls. A quick rerun a few seconds or a minute later will then pick them up once they’ve fully landed in the DLQ.

What you can do to smooth this out:

Introduce a short “warm-up” or delay (for example, 30–60 seconds) in your schedule so the DLQ trigger has time to see all newly dead-lettered messages. Tune your Service Bus trigger settings, you can increase the polling interval, batch size, or prefetch count in the trigger’s settings to grab more messages per poll.

As a best practice, consider using automatic DLQ forwarding (Service Bus redrive) or an Azure Function/Logic App pattern that moves DLQ messages back into your main queue on a continuous basis instead of a once-a-day job.

Lastly, you can always drill into your trigger history and run history to confirm exactly when the trigger fired.
Karthik K Koneru 81 Reputation points

2026-04-01T17:52:56.4133333+00:00

Thank you for the explanation. This helps clarify why the behavior is occurring, especially around the broker-side DLQ move and the polling/peek-lock nature of the Logic Apps trigger.

Our use case, however, is slightly stricter: we rely on a once‑per‑day DLQ reprocessing workflow and need it to deterministically pick all DLQ messages, regardless of deadLetterReason, without requiring manual reruns or tuning based on timing windows.

While introducing delays or increasing polling frequency can reduce the likelihood of misses, they still feel more like mitigations than a guaranteed solution for batch-style DLQ reprocessing.

Would you be open to a quick call to discuss recommended design patterns that ensure full DLQ coverage (especially when mixing automatic and manual dead-lettering)?

I think a short discussion would help us align on the most robust approach.

Appreciate your insights and guidance. Thanks again.
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-03T17:04:04.7166667+00:00

@Karthik K Koneru ,I have reached out to you over private message. Please check and respond.
Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-04-06T19:51:15.2533333+00:00
Karthik K Koneru,

You can confirm the root cause by checking:

Message properties in DLQ

DeadLetterReason

DeadLetterErrorDescription

Logic App trigger settings

Verify if Auto-complete is enabled.

Run history inputs

Check if the same LockToken is used multiple times.

2 answers

Your answer

Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-03-28T00:14:43.1066667+00:00

Hi @Karthik K Koneru , following up to see if the above provided information is helpful. Please let me know if you have any questions.
Karthik K Koneru 81 Reputation points

2026-03-31T13:40:52.0633333+00:00

Thank you for the detailed explanation — that clarified why the Logic App run is marked Failed even though the message ends up in the DLQ. That part makes sense now.

I have a follow‑up question regarding DLQ reprocessing behavior, specifically for messages that were automatically dead‑lettered by Service Bus with (deadLetterReason = MaxDeliveryCountExceeded)
Messages are dead‑lettered in two ways:
Automatically by Service Bus when max delivery count is exceeded.
Manually by Logic Apps when a downstream API call fails

We have a secondary Logic App workflow that runs once daily to:

Read messages from the DLQ and Re‑enqueue them to the main queue for reprocessing.
Messages that were manually dead‑lettered are consistently picked up by the DLQ reprocessing workflow.However, messages with (deadLetterReason = MaxDeliveryCountExceeded) are sometimes not picked up on the first run of the DLQ reprocessing workflow.If I re‑run the same workflow, those messages are then picked up and processed.
Is there any known or expected behavior where automatically dead‑lettered messages (MaxDeliveryCountExceeded) are not processed on the first run?
I’d appreciate any guidance or best practices. Thanks in advance for the help!
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-01T01:15:30.6366667+00:00

@Karthik K Koneru This isn't a bug in Logic Apps or Service Bus, but a side-effect of how the Service Bus DLQ trigger polls and how “automatic” dead-lettering happens under the covers:

Automatic dead-letter (MaxDeliveryCountExceeded) happens entirely in the broker and then the message shows up in the DLQ.

The Logic App Service Bus DLQ trigger is a polling trigger (peek-lock style), so there can be a small delay from the time the broker moves the message to DLQ and when that message becomes visible to your trigger.

If your daily DLQ-reprocessing runs immediately after a batch of messages auto-dead-letter, some messages might not yet be surfaced when the trigger polls. A quick rerun a few seconds or a minute later will then pick them up once they’ve fully landed in the DLQ.

What you can do to smooth this out:

Introduce a short “warm-up” or delay (for example, 30–60 seconds) in your schedule so the DLQ trigger has time to see all newly dead-lettered messages. Tune your Service Bus trigger settings, you can increase the polling interval, batch size, or prefetch count in the trigger’s settings to grab more messages per poll.

As a best practice, consider using automatic DLQ forwarding (Service Bus redrive) or an Azure Function/Logic App pattern that moves DLQ messages back into your main queue on a continuous basis instead of a once-a-day job.

Lastly, you can always drill into your trigger history and run history to confirm exactly when the trigger fired.
Karthik K Koneru 81 Reputation points

2026-04-01T17:52:56.4133333+00:00

Thank you for the explanation. This helps clarify why the behavior is occurring, especially around the broker-side DLQ move and the polling/peek-lock nature of the Logic Apps trigger.

Our use case, however, is slightly stricter: we rely on a once‑per‑day DLQ reprocessing workflow and need it to deterministically pick all DLQ messages, regardless of deadLetterReason, without requiring manual reruns or tuning based on timing windows.

While introducing delays or increasing polling frequency can reduce the likelihood of misses, they still feel more like mitigations than a guaranteed solution for batch-style DLQ reprocessing.

Would you be open to a quick call to discuss recommended design patterns that ensure full DLQ coverage (especially when mixing automatic and manual dead-lettering)?

I think a short discussion would help us align on the most robust approach.

Appreciate your insights and guidance. Thanks again.
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-03T17:04:04.7166667+00:00

@Karthik K Koneru ,I have reached out to you over private message. Please check and respond.
Praveen Kumar Gudipudi 2,275 Reputation points Microsoft External Staff Moderator

2026-04-06T19:51:15.2533333+00:00

Karthik K Koneru,

You can confirm the root cause by checking:

Message properties in DLQ

DeadLetterReason

DeadLetterErrorDescription

Logic App trigger settings

Verify if Auto-complete is enabled.

Run history inputs

Check if the same LockToken is used multiple times.

Answer 1

Hi @Karthik K Koneru ,

Thanks for reaching out to Microsoft Q&A.

The run is marked as “Failed” because one of your connector actions (the manual “Dead-letter the message” step) returned a BadRequest, even though Service Bus did end up moving the message into the DLQ. A run is considered Failed as soon as any action returns a non-2xx HTTP response, regardless of whether the backend state ended up the way you wanted.

Why this happens in your workflow:

Service Bus automatically dead-letters messages once they exceed the max delivery count (the message properties show deadLetterReason = MaxDeliveryCountExceeded).
Your Logic Apps step then tries to manually dead-letter that same message by lock token. Because the message’s already gone, the Service Bus connector API returns a 400 BadRequest.
Logic Apps flags that connector call as a failure, so the overall run status is Failed—even though the message did end up in the DLQ.

Steps to resolve it:

Add proper error handling around your dead-letter action. Put it into a Scope or a nested workflow with “Configure run after” so that the BadRequest is caught and treated as a success. For example, use an HTTP Response or a “Terminate” action with status = Succeeded.
Only call manual dead-letter when you’re sure the lock token is still valid. For example, use a delay or check DeliveryCount before you invoke the dead-letter connector.

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

In Logic Apps, the overall run status is driven purely by the action statuses in the run history, not by what later happens to the message in Service Bus.

From the screenshots and the documentation, the behavior is explained as follows:

In the run history, the “Dead‑letter the message in a queue” action shows status Failed with error BadRequest.
According to the run‑history rules, if any action in a run has status Failed and there is no subsequent action configured to handle that failure, the entire workflow run is marked as Failed.
- For Consumption workflows: “Failed – At least one action in the run failed. No subsequent actions in the workflow were set up to handle the failure.”
- For Standard workflows: the same definition applies to the run status.
Service Bus can still move the message to the DLQ (for example, because MaxDeliveryCount is exceeded) independently of the Logic Apps action result. That is why the message appears in the DLQ with deadLetterReason = MaxDeliveryCountExceeded even though the Logic Apps action reports BadRequest and Failed.
The run history therefore correctly reflects that the Logic Apps action failed, even though the broker (Service Bus) ultimately placed the message in the DLQ for its own reasons.

To avoid the whole run being marked as Failed when this is an expected condition, configure explicit failure handling on that action (for example, using runAfter conditions, scopes with Succeeded/Failed branches, or try/catch patterns) so that the failure is treated as handled and the run can complete with Succeeded.

References:

Share via

Why Logic Apps run history is showing failure, while the message is processed successfully?

2 answers

Your answer