How to Troubleshoot Azure Functions Service Bus Trigger Issues

Overview

Azure Functions integrates with Azure Service Bus via triggers and bindings, allowing you to build event-driven applications that react to queue and topic messages. The Service Bus trigger uses PeekLock mode to receive messages, automatically manages message locks, and completes or abandons messages based on function execution results.

When this integration encounters problems, you may see one or more of these symptoms:

• Messages accumulate in the queue or topic subscription and are not processed
• Functions execute but messages end up in the dead-letter queue (DLQ)
• MessageLockLostException or ServiceBusException errors in Application Insights
• Messages are processed multiple times (duplicate processing)
• The function app shows connection failures or AMQP errors in logs
• Trigger scaling does not work as expected — too few or too many instances
• Session-enabled queues stop processing after a period of time

This blog walks you through how the Service Bus trigger works internally, what can go wrong, and — most importantly — how to systematically diagnose and resolve these failures.

Understanding How the Service Bus Trigger Works

Before diving into troubleshooting, it is important to understand how the Service Bus trigger processes messages.

Message Processing Flow

Service Bus Namespace (Queue or Topic/Subscription)
  → Functions runtime discovers serviceBusTrigger binding
    → ServiceBusProcessor created (PeekLock mode)
      → Message received → Lock acquired
        → Function invoked with message payload
          → Function succeeds → Message Completed ✓
          → Function fails → Message Abandoned → Redelivered
            → Max delivery count reached → Dead-Letter Queue

The Functions runtime uses the Azure.Messaging.ServiceBus SDK under the hood. It creates a ServiceBusProcessor (or ServiceBusSessionProcessor for session-enabled entities) that manages the message receive loop, lock renewal, and concurrency.

Key Concepts

host.json Configuration Reference

All Service Bus trigger settings are configured under the extensions.serviceBus section of host.json:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "clientRetryOptions":{
                "mode": "exponential",
                "tryTimeout": "00:01:00",
                "delay": "00:00:00.80",
                "maxDelay": "00:01:00",
                "maxRetries": 3
            },
            "prefetchCount": 0,
            "transportType": "amqpWebSockets",
            "webProxy": "https://proxyserver:8080",
            "autoCompleteMessages": true,
            "maxAutoLockRenewalDuration": "00:05:00",
            "maxConcurrentCalls": 16,
            "maxConcurrentSessions": 8,
            "maxMessageBatchSize": 1000,
            "minMessageBatchSize": 1,
            "maxBatchWaitTime": "00:00:30",
            "sessionIdleTimeout": "00:01:00",
            "enableCrossEntityTransactions": false
        }
    }
}

 

Note: The clientRetryOptions settings apply only to interactions with the Service Bus service. They do not affect retries of function executions. For function-level retries, see Azure Functions error handling and retries.

Issue Categories

Common Causes and Solutions

1. Connection String or Configuration Errors

Symptoms:

• Function does not trigger at all
• Error: "MessagingEntityNotFoundException" — queue or topic not found
• Error: "No connection string configured for the Service Bus trigger"
• Error referencing an invalid or missing app setting

Why This Happens:

The Service Bus trigger requires a valid connection to your Service Bus namespace. By default, it looks for an app setting named AzureWebJobsServiceBus. If you specify a custom Connection property on the trigger attribute, the runtime looks for that named setting instead. If the connection string is missing, invalid, or points to the wrong namespace, the trigger cannot create a ServiceBusProcessor and messages will not be processed.

How to Verify:

1. Check your trigger attribute for the Connection property value:[ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection")]
2. Navigate to your Function App → Settings → Configuration → Application settings
3. Verify the connection setting exists and is correctly named
4. For connection string–based connections, confirm the value contains a valid endpoint, SharedAccessKeyName, and SharedAccessKey
5. For managed identity connections, confirm <CONNECTION_NAME>__fullyQualifiedNamespace is set to <your-namespace>.servicebus.windows.net

Solution:

• Set the correct connection string or managed identity configuration in Application Settings
• Verify the queue or topic name in the trigger attribute matches the actual entity name in your Service Bus namespace (names are case-sensitive)
• If using managed identity, ensure the __fullyQualifiedNamespace suffix is used (with double underscores):

{ "ServiceBusConnection__fullyQualifiedNamespace": "myservicebus.servicebus.windows.net" }

Ref: Service Bus trigger — Connections

2. Authentication and Authorization Failures (RBAC / SAS)

Symptoms:

• Error: "Unauthorized access. 'Listen' claim(s) are required to perform this operation."
• Error: "AuthorizationFailedException" or "UnauthorizedException"
• Error: "Attempted to perform an unauthorized operation."
• 401 or 403 errors in Application Insights

Why This Happens:

The Service Bus trigger requires Listen permission on the queue or subscription. If you are using a Shared Access Signature (SAS) policy that does not include the Listen claim, or a managed identity without the correct RBAC role, the runtime cannot receive messages.

For managed identity connections, the identity must be assigned the Azure Service Bus Data Receiver role (or Azure Service Bus Data Owner) at the appropriate scope. For topic subscriptions, the role assignment must have effective scope over the subscription resource, not just the topic.

How to Verify:

1. For SAS-based connections:
   • Go to your Service Bus namespace → Shared access policies
   • Confirm the policy used in your connection string has the Listen claim
   • If your function also sends messages (output binding), the policy needs Send as well
2. For managed identity:
   • Go to your Service Bus namespace → Access control (IAM) → Role assignments
   • Verify your Function App's managed identity has Azure Service Bus Data Receiver
   • For topic triggers, verify the role is assigned at the subscription level (not just the topic)

Solution:

• For SAS: Use a policy that has the required claims, or create a new policy with Listen (and Send if needed)
• For managed identity: Assign the correct role. Use the Azure CLI if the portal does not expose the subscription resource as a scope:

Ref: Grant permission to the identity

3. Message Lock Lost Exceptions

Symptoms:

• Error: "MessageLockLostException: The lock supplied is invalid. Either the lock expired, or the message has already been removed from the queue."
• Messages are processed but then redelivered (duplicate processing)
• Messages eventually end up in the dead-letter queue after repeated failures

Why This Happens:

When the Service Bus trigger receives a message in PeekLock mode, it acquires a lock for a duration configured on the Service Bus entity (default 30 seconds). The Functions runtime automatically renews this lock while your function is executing, up to the maxAutoLockRenewalDuration (default 5 minutes).

A MessageLockLostException occurs when:

1. Function execution exceeds maxAutoLockRenewalDuration — If your function takes longer than 5 minutes (the default), the lock renewal stops and the lock expires. The message becomes available for redelivery.
2. Lock renewal fails due to a transient error — A network blip or Service Bus throttling can prevent a renewal request from succeeding.
3. The entity's lock duration is very short — If the lock duration on the queue or subscription is set lower than the time between renewal attempts, the lock may expire between renewals.
4. Batch processing with long execution times — For batch-triggered functions, maxAutoLockRenewalDuration applies to the entire batch, not individual messages. Note: automatic lock renewal is not supported for batch functions — the lock duration is determined by the entity-level setting.

How to Verify:

1. Check Application Insights for MessageLockLostException entries and note the function execution duration
2. Compare the execution duration against your maxAutoLockRenewalDuration setting
3. Check the lock duration on your Service Bus entity:
   • Go to Service Bus namespace → Queue or Topic/Subscription → Properties
   • Note the Lock duration value

Solution:

• Increase maxAutoLockRenewalDuration in host.json to exceed your longest expected function execution time:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxAutoLockRenewalDuration": "00:10:00"
        }
    }
}

 

• Increase the entity's lock duration on the Service Bus queue or subscription (maximum 5 minutes) to provide a larger window between renewal attempts
• Optimize function execution time — If your function is doing heavy processing, consider:
  • Offloading work to a Durable Functions orchestration
  • Using a queue-based load leveling pattern
  • Breaking long operations into smaller units
• For batch functions — Reduce maxMessageBatchSize so that each batch completes within the entity's lock duration, since automatic lock renewal does not apply to batches

Important: maxAutoLockRenewalDuration only applies to single-message functions. For batch functions, the message lock is governed by the entity-level lock duration setting.

4. Messages Going to the Dead-Letter Queue

Symptoms:

• Messages appear in the dead-letter queue (DLQ) instead of being processed
• The DeadLetterReason on the dead-lettered message shows MaxDeliveryCountExceeded
• Function logs show repeated exceptions for the same message
• Some messages process successfully while others consistently fail

Why This Happens:

When a function throws an unhandled exception, the runtime calls Abandon on the message (when autoCompleteMessages is true). The message is returned to the queue and its DeliveryCount is incremented. Once the delivery count reaches the entity's Max delivery count (default 10), the message is automatically moved to the DLQ by Service Bus.

Common reasons messages repeatedly fail:

• Poison messages with malformed or unexpected content
• Transient dependency failures (database, external API) that affect all retries
• Deserialization errors when the message body does not match the expected type
• Application bugs triggered by specific message content

How to Verify:

1. Check the dead-letter queue using Service Bus Explorer (Azure Portal → Service Bus namespace → Queue → Service Bus Explorer → Dead-letter tab)
2. Inspect the DeadLetterReason and DeadLetterErrorDescription properties on the dead-lettered messages
3. Check Application Insights for exceptions correlated with the message IDs
4. Review the DeliveryCount on the messages — if it equals the max delivery count, the message was redelivered until it was DLQ'd

Solution:

• Fix the root cause — Examine the dead-lettered messages and the corresponding exceptions to identify why processing fails
• Add error handling — Implement try-catch logic and decide whether to complete, dead-letter, or abandon the message explicitly:

[Function(nameof(ProcessMessage))]
public async Task ProcessMessage(
    [ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection",
     AutoCompleteMessages = false)]
    ServiceBusReceivedMessage message,
    ServiceBusMessageActions messageActions)
{
    try
    {
        // Process the message
        await ProcessAsync(message);
        await messageActions.CompleteMessageAsync(message);
    }
    catch (InvalidDataException)
    {
        // Poison message — send to DLQ with a reason
        await messageActions.DeadLetterMessageAsync(message,
            "InvalidData", "Message body could not be deserialized.");
    }
    catch (Exception ex)
    {
        // Transient failure — abandon for retry
        _logger.LogError(ex, "Processing failed, abandoning message {MessageId}",
            message.MessageId);
        await messageActions.AbandonMessageAsync(message);
    }
}

 

• Increase max delivery count on the Service Bus entity if you need more retry attempts before dead-lettering
• Process the DLQ — Set up a separate function or process to monitor and handle dead-lettered messages

Tip: Use ServiceBusMessageActions with AutoCompleteMessages = false. This prevents the runtime from attempting to complete messages after a successful function invocation.

5. Duplicate Message Processing

Symptoms:

• Business logic executes more than once for the same message
• Database records or downstream operations are duplicated
• Logs show the same MessageId processed by multiple instances or multiple times on the same instance

Why This Happens:

Duplicate processing can occur in several scenarios:

1. Message lock lost — If the lock expires (see Issue 3), the message becomes available and is picked up again — either by the same or a different instance
2. Function timeout — If the function exceeds the functionTimeout in host.json (default 5 minutes for Consumption, 30 minutes for Premium/Dedicated), the runtime cancels the invocation but the message may have already been partially processed
3. Instance restarts — If the Function App instance restarts or is scaled down during processing, in-flight messages are abandoned and redelivered
4. At-least-once delivery — Service Bus guarantees at-least-once delivery. In rare cases, a message may be delivered more than once even without lock expiration

How to Verify:

• Search Application Insights for the same MessageId appearing in multiple invocations:

traces
| where message has "MessageId"
| summarize count() by tostring(customDimensions["MessageId"])
| where count_ > 1

 

• Check if MessageLockLostException precedes the duplicate invocation
• Review functionTimeout settings in host.json

Solution:

1. Make your function idempotent — Design processing logic so that executing it multiple times with the same message produces the same result. Common patterns:
   • Use the MessageId as a deduplication key
   • Use upserts instead of inserts in your database
   • Check for an existing record before processing
2. Enable duplicate detection on the Service Bus entity:
   • Set requiresDuplicateDetection: true when creating the queue or topic
   • Configure duplicateDetectionHistoryTimeWindow (default 10 minutes)
3. Address lock expiration — Follow the guidance in Issue 3 to prevent lock-related redelivery
4. Use sessions for ordered, exactly-once-per-session processing when your business logic requires it

6. Scaling Issues — Messages Accumulating in the Queue

Symptoms:

• Message count in the queue or subscription grows steadily
• Only one or a few instances are running despite a large backlog
• Target-based scaling does not appear to be working
• Messages are processed very slowly

Why This Happens:

Azure Functions uses target-based scaling for Service Bus triggers on Consumption, Elastic Premium and Flex Consumption plan. The scale controller monitors the entity's message count and active message count to decide how many instances to allocate. Scaling issues can arise from:

1. maxConcurrentCalls is too low — Each instance processes at most maxConcurrentCalls messages concurrently. If this is set to 1 and messages take 1 second each, a single instance can only process ~60 messages/minute.
2. functionTimeout or long processing — If each message takes a long time, fewer messages are processed per instance and scale-out is needed.
3. Consumption plan cold start — New instances take time to spin up and establish connections.
4. Premium plan with VNET_ROUTE_ALL — VNet integration can slow cold starts due to DNS resolution and private endpoint setup.
5. Batch size misconfigured — For batch-triggered functions, a very large maxMessageBatchSize with long processing per message can bottleneck throughput.

How to Verify:

1. Check the active message count on your Service Bus entity over time
2. Review the instance count in Metrics → Function App → Instance Count
3. Check Application Insights for function invocation durations
4. Verify maxConcurrentCalls and other settings in host.json

Solution:

• Increase maxConcurrentCalls if your function can safely handle more parallelism:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentCalls": 32
        }
    }
}

• Use prefetchCount to reduce latency by pre-fetching messages from the broker:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "prefetchCount": 32
        }
    }
}

 

• Use batched functions for high-throughput scenarios — process multiple messages per invocation:

[Function(nameof(ProcessBatch))]
public void ProcessBatch(
    [ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection",
     IsBatched = true)]
    ServiceBusReceivedMessage[] messages)
{
    foreach (var message in messages)
    {
        // Process each message
    }
}

• Optimize function execution time — Reduce the per-message processing duration to allow higher throughput per instance
• For Premium plans, consider setting FUNCTIONS_WORKER_PROCESS_COUNT to use multiple language worker processes per instance for out-of-process language workers

7. Session-Enabled Queue or Subscription Issues

Symptoms:

• Session processing stops after some time
• Error: "SessionLockLostException"
• Only some sessions are being processed while others are idle
• Sessions appear "stuck" and messages accumulate

Why This Happens:

When IsSessionsEnabled = true on the trigger, the runtime creates a ServiceBusSessionProcessor. This processor acquires a session lock, processes messages for that session, and then moves to the next session. Issues can arise from:

1. maxConcurrentSessions is too low — The default is 8. If you have many active sessions, some will wait for a processor to become available.
2. sessionIdleTimeout is too short — When no messages arrive for a session within this timeout, the session is released. If messages arrive slightly after the timeout, a new session lock must be acquired, adding latency.
3. Long-running session processing — If processing a message within a session takes longer than the session lock duration, a SessionLockLostException occurs.
4. Single-threaded per session — Within a session, messages are processed sequentially (FIFO). If one message in a session takes very long, it blocks subsequent messages in that session.

How to Verify:

1. Check Application Insights for SessionLockLostException
2. Review the maxConcurrentSessions and sessionIdleTimeout settings in host.json
3. Monitor the number of active sessions on your Service Bus entity

Solution:

• Increase maxConcurrentSessions to process more sessions in parallel:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentSessions": 32,
            "sessionIdleTimeout": "00:02:00"
        }
    }
}

• Increase maxAutoLockRenewalDuration to prevent session lock expiration during long-running processing
• Optimize per-message processing time within sessions
• Review your session design — If you have a very large number of sessions with low message volume per session, consider whether sessions are the right pattern for your use case

8. AMQP Connection and Network Errors

Symptoms:

• Error: "An AMQP error occurred (condition: 'amqp:link:detach-forced')."
• Error: "ServiceBusCommunicationException" or "SocketException"
• Error: "The link 'xxx' is force detached... due to broker shutting down"
• Intermittent connection drops and slow reconnects
• Trigger stops firing after a period of working correctly

Why This Happens:

The Service Bus trigger communicates with the Service Bus namespace over AMQP (TCP port 5671/5672). Connection issues can occur when:

1. Network firewall blocks AMQP ports — Corporate firewalls or NSGs may block the required ports
2. VNet integration without proper routing — Missing service endpoints, private endpoints, or DNS configuration
3. Service Bus namespace throttling — Exceeding the messaging units for your tier causes throttling responses
4. Idle connection timeout — Long-idle connections may be terminated by intermediate network devices
5. Service Bus service maintenance — Broker restarts or failovers can force-detach links

How to Verify:

1. Check Application Insights for ServiceBusCommunicationException or AMQP-related errors
2. Test connectivity from your Function App's network context:
   • For VNet-integrated apps: use Diagnose and solve problems → Network Troubleshooter
   • Test DNS resolution for <namespace>.servicebus.windows.net
   • Test TCP connectivity on port 5671
3. Check Service Bus namespace metrics for throttling (ThrottledRequests metric)
4. Review NSG rules on the Function App's subnet

Solution:

• Allow AMQP traffic — Ensure ports 5671 and 5672 are open outbound in your NSG/firewall rules. Alternatively, switch to WebSockets:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "transportType": "amqpWebSockets"
        }
    }
}

Using amqpWebSockets routes traffic over port 443, which is more likely to be allowed by corporate firewalls.

• Configure private endpoints for VNet-integrated apps:
  • Create a private endpoint for your Service Bus namespace
  • Configure private DNS zone privatelink.servicebus.windows.net
  • Ensure DNS zone is linked to your VNet
• Scale up the Service Bus tier if throttling is the issue — check the namespace's messaging units and consider upgrading from Basic to Standard or Premium
• Configure retry options in host.json for transient failures:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "clientRetryOptions": {
                "mode": "exponential",
                "maxRetries": 5,
                "delay": "00:00:01",
                "maxDelay": "00:01:00",
                "tryTimeout": "00:02:00"
            }
        }
    }
}

 

9. Extension Bundle or NuGet Package Version Mismatch

Symptoms:

• Error: "The 'serviceBusTrigger' binding type is not registered"
• Error: "Microsoft.Azure.WebJobs.Host: Error indexing method..."
• Function works locally but fails in Azure
• Missing features (e.g., ServiceBusMessageActions, IsBatched) that should be available

Why This Happens:

The Service Bus trigger implementation lives in the extension package. For non-compiled languages (Node.js, Python, PowerShell, Java) it is delivered via extension bundles. For compiled .NET apps, it comes from NuGet packages. If the version is outdated or mismatched, trigger types may not be registered or newer features may be unavailable.

How to Verify:

1. For .NET apps: Check the version of the Service Bus extension NuGet package in your .csproj file
2. For non-.NET apps: Check the extensionBundle version range in host.json
3. Compare against the latest available versions on NuGet

Solution:

• For .NET Isolated apps, update to the latest extension:

<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.ServiceBus" Version="5.22.0" />

• For non-.NET apps, ensure your extension bundle is current:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.*, 5.0.0)"
    }
}

• For features like ServiceBusMessageActions and IsBatched, ensure you are on extension version 5.14.1 or later

10. Function Timeout Causing Message Redelivery

Symptoms:

• Function execution is cancelled mid-processing
• CancellationToken is triggered before function completes
• Messages are redelivered and may eventually end up in the DLQ
• Application Insights shows FunctionTimeoutException

Why This Happens:

Azure Functions enforces a maximum execution timeout per invocation. The default depends on your hosting plan:

Ref: Function app timeout duration

If your Service Bus-triggered function exceeds this timeout, the runtime cancels the invocation. The message is abandoned and redelivered by Service Bus.

How to Verify:

• Check Application Insights for FunctionTimeoutException
• Review function execution durations in Application Insights:

requests
| where name == "ProcessMessage"
| summarize avg(duration), max(duration), percentile(duration, 95) by bin(timestamp, 1h)

 

• Check the functionTimeout setting in host.json

Solution:

• Increase functionTimeout in host.json (within plan limits):

{ "version": "2.0", "functionTimeout": "00:10:00" }

 

• Upgrade your plan if you need longer execution times — Premium and Dedicated plans support unlimited timeout
• Optimize processing — Offload long-running work to Durable Functions, or use the claim-check pattern to move heavy payloads out of the message
• Use the CancellationToken to gracefully handle timeout and avoid partial processing:

[Function(nameof(ProcessMessage))]
public async Task ProcessMessage(
    [ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection")]
    ServiceBusReceivedMessage message,
    CancellationToken cancellationToken)
{
    await DoWorkAsync(message, cancellationToken);
}

 

Using Diagnose and Solve Problems

The Azure Portal provides built-in diagnostics for Service Bus integration issues.

How to Access:

1. Navigate to your Function App in the Azure Portal
2. Select Diagnose and solve problems from the left menu
3. Search for relevant detectors:

These detectors run automated checks and provide targeted recommendations.

Quick Troubleshooting Checklist

Use this checklist to systematically diagnose Service Bus trigger issues:

• [ ] Connection: Is the Service Bus connection string or managed identity configuration set correctly in Application Settings?
• [ ] Entity name: Does the queue/topic/subscription name in the trigger attribute match the actual Service Bus entity?
• [ ] RBAC: For managed identity, does the Function App have Azure Service Bus Data Receiver role?
• [ ] Extension version: Is the Service Bus extension (NuGet or extension bundle) up to date?
• [ ] host.json: Is the serviceBus section configured correctly under extensions?
• [ ] Message locks: Is maxAutoLockRenewalDuration sufficient for your function's execution time?
• [ ] Dead-letter queue: Are messages accumulating in the DLQ? Check DeadLetterReason.
• [ ] Function timeout: Is your function completing within the plan's timeout limit?
• [ ] Network: For VNet-integrated apps, can the app reach the Service Bus namespace on the required ports?
• [ ] Scaling: Are enough instances allocated? Check instance count vs. message backlog.
• [ ] Exceptions: Check Application Insights for the first and most frequent exceptions.
• [ ] Diagnose and Solve: Have you run the built-in detectors in the Azure Portal?

Conclusion

Azure Functions Service Bus trigger issues span a wide range — from simple connection misconfigurations to complex message lock timing problems. The key to efficient troubleshooting is a systematic approach:

Key Takeaways:

1. Start with the basics — Verify connection settings, entity names, and permissions first. Most issues are configuration-related.
2. Understand the lock lifecycle — maxAutoLockRenewalDuration, entity lock duration, and function execution time must be tuned in concert to prevent MessageLockLostException and duplicate processing.
3. Design for at-least-once delivery — Make your functions idempotent. Service Bus guarantees at-least-once, not exactly-once.
4. Use ServiceBusMessageActions for control — Disable autoCompleteMessages and settle messages explicitly for production-grade error handling.
5. Monitor the dead-letter queue — DLQ messages are a direct signal that something is failing. Inspect them regularly.
6. Tune concurrency for throughput — maxConcurrentCalls, prefetchCount, and batching settings significantly impact throughput.
7. Apply one fix at a time — Change one setting, restart, and recheck. Avoid multiple simultaneous changes that obscure which fix resolved the issue.

If you continue to experience issues after following these steps, consider opening a support ticket with Microsoft Azure Support, providing:

• Function App name and resource group
• Timestamp of when the issue started
• Application Insights exceptions and traces around the failure time
• Service Bus entity configuration (lock duration, max delivery count, sessions)
• host.json serviceBus configuration
• Recent deployment or configuration changes
• Networking configuration details (if VNet-integrated)

References

• Azure Service Bus trigger for Azure Functions
• Azure Service Bus bindings — host.json settings
• Azure Functions error handling and retries
• Target-based scaling for Service Bus
• Service Bus PeekLock behavior
• Azure Functions networking options
• Azure Functions diagnostics
• Troubleshoot Azure Functions
• Service Bus dead-letter queues
• Azure Service Bus RBAC roles

Have questions or feedback? Leave a comment below.