Verified history
This means HyperObserve has not found sufficient first-party evidence for a dated before-and-after event. It does not mean Azure Functions has never changed. Undated values are kept in the current baseline below instead of being presented as history.
Current monitored baseline
HyperObserve currently monitors 3 scoped observations for Azure Functions. The baseline covers hosting-plan execution timeout, HTTP load-balancer response ceiling, language worker startup. Each value retains its plan, product, endpoint, region, account, or runtime qualifier so a future change can be compared against the correct scope.
| Constraint | Current value | Scope | Verified source |
|---|---|---|---|
| hosting-plan execution timeoutThe functionTimeout host.json setting controls the app within the plan ceiling. | Consumption: 5m default, 10m max; other plans: 30m default, unbounded max with caveats | Hosting-plan specific | MicrosoftAug 22, 2026 |
| HTTP load-balancer response ceilingThe HTTP response cap applies even when the hosting plan permits longer background execution. | 230 seconds | HTTP-triggered functions | MicrosoftAug 22, 2026 |
| language worker startupThe worker process must start and initialize within the documented window. | 60 seconds | All hosting plans | MicrosoftAug 22, 2026 |
Tracked constraints and impact
Hosting-plan execution, HTTP response, startup, memory, and scaling constraints. A change is recorded only when it alters a constraint developers can act on, such as capacity planning, request shaping, model selection, deployment configuration, storage design, retry behavior, or account budgeting.
Azure Functions Execution Timeout
Azure Functions Execution Timeout, verified against Azure Functions's official documentation with scope, implementation impact, caveats, and a direct check.
Azure Functions HTTP Response Timeout
Azure Functions HTTP Response Timeout, verified against Azure Functions's official documentation with scope, implementation impact, caveats, and a direct check.
Azure Functions Worker Startup Limit
Azure Functions Worker Startup Limit, verified against Azure Functions's official documentation with scope, implementation impact, caveats, and a direct check.
How a change is verified
- Compare the current first-party statement with the previously stored observation, including the exact plan, model, runtime, endpoint, region, and account scope.
- Separate a true product change from documentation clarification, temporary capacity, configurable account state, or a limit that applies to a different execution path.
- Preserve the old and new values, official source, effective date when disclosed, detection date, and practical impact. If those elements cannot be supported, no historical event is published.
Official sources monitored
These first-party documents support the current Azure Functions baseline. HyperObserve links directly to them so you can confirm the live wording before making a production decision.
Execution timeout, HTTP response, startup, and hosting-plan limits