Expose `PrimaryHostCoordinator` lease timeout and renewal interval as optional host configuration

[maximilianoe]

Summary

Azure Functions enables PrimaryHostCoordinator and maintains a Blob lease at:

azure-webjobs-hosts/locks/<host-id>/host

The current behavior is effectively:

• LeaseTimeout = 15 seconds
• RenewalInterval = 12 seconds

For a continuously active Function App, this produces one RenewBlobLease approximately every 12 seconds.

I propose exposing PrimaryHostCoordinatorOptions.LeaseTimeout and PrimaryHostCoordinatorOptions.RenewalInterval as optional customer configuration, while preserving the existing defaults unless explicitly overridden.

Evidence

On a Flex Consumption Function App using managed identity/OAuth for AzureWebJobsStorage, Storage diagnostics show:

OperationName: RenewBlobLease
URI: https://<account>.blob.core.windows.net/azure-webjobs-hosts/locks/<host-id>/host?comp=lease
AuthenticationType: OAuth
UserAgent: azsdk-net-Storage.Blobs/12.22.1
Status: 200 Success

Measured cadence:

~1 renewal / 12 seconds
~5 / minute
~300 / hour
~7,200 / day
~223,200 / 31-day month

This is from a single continuously active host, not scale-out multiplication.

In my account, these renewals are the dominant contributor by count to the Blob Storage All Other Operations meter and cost roughly €0.11–€0.12/month for one continuously active Function App. The amount is small per app, but it is fixed background overhead and scales with the number of continuously active apps.

Existing runtime support

PrimaryHostCoordinatorOptions already exposes:

public TimeSpan LeaseTimeout { get; set; }
public TimeSpan? RenewalInterval { get; set; }

with LeaseTimeout constrained to 15–60 seconds.

PrimaryHostCoordinator uses:

RenewalInterval ?? LeaseTimeout.Add(TimeSpan.FromSeconds(-3))

So the runtime already supports configurations such as:

LeaseTimeout = 60 seconds
RenewalInterval = 30 seconds

The missing piece is a supported Azure Functions configuration binding.

The existing host.json singleton settings do not apply here; they configure SingletonOptions, not the Primary Host Coordinator /host lease.

Proposal

Expose these options through host.json and the standard app-setting override mechanism, for example:

{
  "primaryHostCoordinator": {
    "leaseTimeout": "00:01:00",
    "renewalInterval": "00:00:30"
  }
}

with equivalent overrides such as:

AzureFunctionsJobHost__primaryHostCoordinator__leaseTimeout=00:01:00
AzureFunctionsJobHost__primaryHostCoordinator__renewalInterval=00:00:30

The exact section name is not important.

The existing 15-second lease / 12-second renewal behavior should remain the default. Customers who opt into longer values would explicitly accept the corresponding failover tradeoff.

Benefit

For one continuously active host:

Configuration	Monthly renewals	Reduction
Current: 15s lease / 12s renewal	~223,200	—
60s lease / 30s renewal	~89,280	60%
60s lease / 57s renewal	~46,990	79%

60s / 30s keeps more retry margin; 60s / 57s minimizes transactions while preserving the current LeaseTimeout - 3s strategy.

Exposing both settings lets customers choose that tradeoff without changing existing defaults.

Related issues

• Improve Host Lock Renewals #2592 — Improve Host Lock Renewals
• Cost Regression due to added Health Check when using GPv2 Storage #11765 — Cost Regression due to added Health Check when using GPv2 Storage

#2592 already discusses this renewal strategy from a reliability perspective. This request is specifically to expose the existing coordinator options as an opt-in customer setting for workloads that want to choose their own storage-cost/failover tradeoff.

Environment

Plan: Azure Functions Flex Consumption
Runtime: Functions v4
Worker: Node.js
Storage: GPv2
Authentication: Managed Identity / OAuth
Observed lease: azure-webjobs-hosts/locks/<host-id>/host
Observed renewal cadence: ~12 seconds