Process Queue Messages with Azure Functions (2026)

Azure Functions can process messages from queues, but they often process them in batches, which can lead to unexpected behavior if you’re not careful about how your function handles state.

Let’s see this in action. Imagine you have a Storage Queue with messages like this:

{"OrderId": "123", "Status": "Processing"}
{"OrderId": "456", "Status": "Processing"}
{"OrderId": "789", "Status": "Processing"}

And an Azure Function triggered by this queue, written in C#:

using System.Collections.Generic;
using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;

public static class QueueProcessor
{
    // In a real scenario, you'd likely use a distributed cache or database
    // to track order status across multiple function invocations.
    // For this example, we'll simulate a shared state with a static variable,
    // but understand this is NOT suitable for production due to concurrency issues.
    private static Dictionary<string, string> orderStatuses = new Dictionary<string, string>();

    [FunctionName("ProcessQueueMessages")]
    public static void Run([QueueTrigger("myqueue-items")] string myQueueItem, ILogger log)
    {
        log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");

        // Simulate processing and updating status
        var orderData = System.Text.Json.JsonSerializer.Deserialize<OrderInfo>(myQueueItem);

        if (orderStatuses.ContainsKey(orderData.OrderId))
        {
            log.LogWarning($"Order {orderData.OrderId} already processed. Current status: {orderStatuses[orderData.OrderId]}");
            // In a real system, you might re-queue or log this as a duplicate.
            return;
        }

        // Simulate some work
        System.Threading.Thread.Sleep(1000); // Simulate 1 second of work

        orderStatuses[orderData.OrderId] = "Processed";
        log.LogInformation($"Order {orderData.OrderId} marked as Processed.");
    }

    public class OrderInfo
    {
        public string OrderId { get; set; }
        public string Status { get; set; }
    }
}

When this function runs, Azure Functions by default will try to process multiple messages concurrently. If two instances of your function pick up messages for the same OrderId at almost the same time, the orderStatuses dictionary (which is not truly shared or safe for concurrency in this example) could lead to race conditions. The ContainsKey check might pass for both, and then both might try to update the status, or one might overwrite the other.

The problem Azure Functions solves here is efficiently processing a large volume of work items from a queue without you having to manage the polling, scaling, and execution infrastructure. You define what to do with a message, and the Azure Functions host handles the how — scaling up to handle bursts of messages, scaling down to zero when idle, and retrying failed executions. The host manages the lifecycle of each function instance, including how many messages it picks up at once.

Internally, the queue trigger works by having a host process that continuously polls the specified queue. When messages are available, the host can decide to scale out the number of Function App instances. Each instance then receives a batch of messages to process. By default, for Azure Storage Queues, this batch size can be up to 10 messages at a time. Your function code then iterates through this batch.

The key levers you control are:

Batch Size: You can configure the maximum number of messages processed by a single function invocation. For Azure Storage Queues, this is done via an IsBatched setting in the QueueTrigger attribute, which is true by default. If you set IsBatched = false, each message will trigger a separate invocation, which can be simpler for stateful operations but less efficient for high throughput.
Concurrency: The Functions host manages the number of concurrent executions. You can influence this through host.json settings like maxConcurrentCalls (for a specific trigger) and concurrency.cpuPercentage or concurrency.memoryPercentage (for overall app concurrency).
Message Handling: How your function code handles errors, retries, and idempotency is crucial. For queue messages, a common pattern is to ensure your processing logic is idempotent – meaning processing the same message multiple times has the same effect as processing it once. This is critical because queue messages can be delivered more than once, especially if a function crashes mid-processing.

A common pitfall is assuming a single function invocation will process only one message. When IsBatched is true (the default for Storage Queues), your function receives a collection of messages. If your code doesn’t correctly iterate and process each item within the batch, or if it relies on shared in-memory state that isn’t thread-safe or distributed, you’ll encounter issues. For example, if your function logs "Processing Order X" and then crashes before completing, the message might be redelivered, and if you’re not handling duplicates, you might process it again.

To handle state reliably across potentially multiple, concurrent function invocations processing batches of messages, you should use an external, distributed store like Azure Cosmos DB, Azure Cache for Redis, or Azure Table Storage. Your function would then read the current state from this store, perform its logic, and write the updated state back, all within a single invocation. This ensures that even if multiple function instances are running, they are all consulting and updating the same, authoritative state source.

The next thing you’ll likely encounter is managing poison messages, which are messages that repeatedly fail processing and can block the queue.