A cloud-based JavaScript application securely processes data and distributes it to servers across a global network.
Azure Front Door edge actions have reached general availability. Microsoft's Azure Updates feed lists the item as "Launched", which the page defines as fully released, production-ready and open to all Azure customers. The feed entry (update 579310) was timestamped November 10, 2026. The visible announcement text is thin, so it gives no pricing or changes from preview. What follows draws on Microsoft Learn's current documentation, last updated November 6, 2026, and on the preview-era coverage.

A cloud-based JavaScript application securely processes data and distributes it to servers across a global network. What edge actions are​

Edge actions let you run custom JavaScript at Azure Front Door points of presence (PoPs). They can modify client request and response properties before Front Door continues processing traffic. The documentation says the feature applies to Front Door Standard and Premium.

The feature is not a general-purpose compute platform. It is a small, bounded hook in the Front Door pipeline. Microsoft says the code runs in a secure, isolated Hyperlight micro-VM inside the Front Door edge server.

From preview to GA​

Edge actions were announced in public preview in the summer of 2026. Microsoft's Azure Networking blog described lightweight JavaScript functions that execute as part of Front Door request processing. At that stage they ran during the client request phase and attached to routes through rule sets.

The current documentation covers both client request and client response invocation points. I could not confirm from the launch notice whether response-phase support is new at GA or arrived during preview. Check that point yourself before you plan around it.

A caution about Microsoft's own samples repository. Its README still describes a "select customer preview" stage. That wording is out of date next to the GA notice and the Learn documentation. Use the repo for code samples, not as a statement of availability.

Documented scenarios​

Microsoft's documentation lists these supported scenarios:

  • A/B experimentation
  • Request and response header manipulation
  • Request rejection
  • Dynamic origin selection
  • URL rewrite and URL redirect
  • JSON Web Token (JWT) validation

JWT validation is a documented scenario. That does not mean you should move all of your authentication to edge code. The 10 ms budget below is tight, and your origin still needs its own authorization checks.

Limits to design around​

Each Edge Action resource has these limits:

ConstraintLimit
Code size16 KB
Versions per resource3
Execution time10 ms
Resources per subscription100

JavaScript is the only supported language. The 10 ms limit fails open. If execution goes beyond it, the service terminates the code and sends the request without Edge Action processing. If your logic enforces a security rule, a timeout could mean the rule is silently skipped. Test that case and keep the origin as the final authority.

Where the code runs in the pipeline​

For a client request, Front Door does the following in order:

  1. The request lands at a PoP and is matched to a profile.
  2. If the domain uses WAF, the WAF rules are evaluated.
  3. The rules engine processes matching rules, and one of them can invoke the Edge Action.
  4. The action modifies request properties, and Front Door continues.

For a client response, the action is invoked after Front Door receives a response from the origin, the cache or internal Front Door functionality.

The action runs with an immutable context. It holds the server variables, the healthy origins for the matched route, the request's country code, the device type derived from the user-agent, and the current date-time. That context is enough for geo-based or device-based decisions without calling an external service.

Getting an action running​

  1. In the portal, create an Edge Action from the Front Door profile (Settings > Edge actions > + Create). You can also search for "Edge Actions" in the portal and create it as a standalone resource.
  2. Add a version under Settings > Versions. Write the JavaScript in the browser or upload a file. An upload can take up to 10 minutes. Confirm the provisioning state shows succeeded.
  3. Set a default version.
  4. Attach the action to a route. Creating the resource does not do this, and nothing runs until you attach it.

Microsoft documents three attachment paths:

  • The easy-attach flow on the profile's Edge actions page.
  • Manual rule-set creation, where the rule action is "Invoke Edge Action" and you pick Client Request or Client Response.
  • The Attachments view on the Edge Action resource.

If you reuse a rule set, note that every rule in it applies to the route, including rules added or changed later.

Portal tests are local simulations, not live traffic. Microsoft says to validate through Front Door after attaching the action to a route.

Safer rollouts with execution filters​

Execution filters route requests to a non-default version based on a header you configure. Microsoft suggests them for canary rollouts, header-based A/B tests and validating new versions. Its example uses a header named test with the value execution.

Pick your own header name and value in production. Treat the header as a convenience for testing, not as authorization. Any version an execution filter references is protected from deletion or upgrade while it is in use.

Monitoring and troubleshooting​

You can send Edge Action logs to Log Analytics through diagnostic settings, the same way as other Front Door logs. The EdgeActionConsoleLog table has these columns:

  • TimeGenerated
  • TrackingReference
  • LogMessage, which carries whatever your code writes with console.log
  • EdgeActionVersion
  • Type
  • ResourceId

You can match the tracking reference to access or WAF logs. Microsoft says the X-Azure-Ref header carries it to the client and the origin.

For a quick check on whether an action ran, look at edgeActionsStatusCode in the Front Door access logs. A value of 200 means successful execution. A value of 503 means an error occurred during execution.

Cost​

Pricing has two parts: the number of invocations, and execution time beyond 1 ms per invocation. Microsoft's documentation does not give rates on that page. Check the Azure Front Door pricing page and model your request volume first. An action attached to a high-traffic route can add up quickly.

What to do now​

  • Preview users should compare their code against the 16 KB and 10 ms limits. They should also confirm their rule sets and routes behave as expected under GA.
  • Teams considering the feature should start with low-risk uses such as headers, redirects and A/B tests. Keep JWT validation and other security logic as a second layer in front of origin checks, not a replacement for them.
  • Treat the GA label as a statement about production readiness. The notice does not say whether limits, regions or pricing changed. Check the pricing page and your own subscription before you roll it out.
 

References

  1. (Launched) Generally Available: Azure Front Door edge actions Azure Updates 2026-11-10T18:55:09Z
  2. Introducing Azure Front Door edge actions - Bringing secure, programmable logic to the edge techcommunity.microsoft.com
  3. Edge Actions - Azure Front Door learn.microsoft.com