Unexpected Azure Bill Increase (₹30k → ₹5.16L) Due to Azure Functions Behind Static Web App – Seeking Root Cause Validation and Billing Guidance

Question

Unexpected Azure Bill Increase (₹30k → ₹5.16L) Due to Azure Functions Behind Static Web App – Seeking Root Cause Validation and Billing Guidance

Sanjay Vitkare 0

Hello Microsoft Team,

We are a company using Azure for our production SaaS platform.

We recently received an Azure invoice of INR 5,16,480.53 for May 2026. Our previous month's invoice was approximately INR 30,000, so this represents a very significant and unexpected increase.

After investigating Cost Analysis, we found that:

April Compute Charges: INR 13,732.89

May Compute Charges: INR 4,04,076.75

The increase is almost entirely attributable to the Compute category.

Cost Analysis points to our Azure Static Web App resource:

oneclarity-frontend-prod

The primary meter appears as:

  **Functions → Standard Execution Time**
```This led us to investigate our Static Web App configuration and deployment setup.

### Deployment Configuration

Our GitHub Actions workflow contained:


```yaml
api_location: "api"

As we understand it, this causes Azure Static Web Apps to deploy the local api/ directory as managed Azure Functions.

Our repository contains:

api/share-blog/function.json
api/writing/function.json

Both are HTTP-triggered Azure Functions.

Static Web App Route Configuration

We also had route rewrites similar to:

{
  "route": "/writing/*",
  "rewrite": "/api/writing/*"
}

and

{
  "route": "/share/blog/*",
  "rewrite": "/api/share/blog/*"
}

As a result:

Requests to /writing/*

Requests to /share/blog/*

were being rewritten to Azure Functions endpoints.

Our Understanding

Our current assumption is:

Azure Static Web Apps automatically deployed the api/ folder as managed Azure Functions.

Every request to the above routes triggered Azure Functions execution.

Search engine crawlers, social preview bots, automated scanners, and public traffic may have repeatedly invoked these endpoints.

Azure billed these executions under:

Functions → Standard Execution Time

This generated the unexpected Compute charges visible on our May invoice.

Planned Fix

We have prepared the following changes:

Change:

api_location: "api"

to

api_location: ""

Remove route rewrites from:

/writing/* → /api/writing/*
/share/blog/* → /api/share/blog/*

Allow those routes to be handled directly by the React SPA instead of Azure Functions.

Questions

Does our root-cause analysis appear technically correct?

Can Azure Static Web Apps managed Azure Functions generate significant Compute charges through repeated public HTTP requests, crawler traffic, or bot traffic?

Is Functions → Standard Execution Time the expected billing meter for this scenario?

Once the above deployment changes are applied, should the execution-time charges stop entirely?

Has Microsoft previously provided billing credits or goodwill adjustments in situations where Azure Functions were unintentionally deployed and consumed unexpectedly due to configuration misunderstandings?

We have already identified and corrected the issue on our side and are primarily looking for confirmation of the technical root cause and guidance regarding possible billing review options.

Thank you for your assistance.Title: Unexpected Azure Bill Increase (₹30k → ₹5.16L) Due to Azure Functions Behind Static Web App – Seeking Root Cause Validation and Billing Guidance

Bharath Y P 9,645 Reputation points Microsoft External Staff Moderator

2026-06-10T13:26:24.2766667+00:00
Hello Sanjay, this definitely sounds concerning, especially when the spike is concentrated in Functions → Standard Execution Time and you didn’t expect significant public traffic to hit those endpoints.

Based on the information you shared, we can’t fully confirm the billing-side root cause from the provided docs alone (the docs included here don’t explicitly cover how Static Web Apps billing meters map to specific request patterns), but your technical theory is plausible: if the Static Web App deployment workflow packages your api/ folder as managed Azure Functions, then traffic that reaches your rewritten routes can result in function executions, which would be billed under the Functions execution-time meter.

Here’s what we can say and what you can do next using the supported guidance:

1) About your technical root-cause hypothesis

Azure Static Web Apps can host backend APIs using Azure Functions (this is a core part of the service’s integration model).

Your workflow conceptually sets where the backend is sourced from (api_location), and you also described route rewrites that send requests from your SPA routes (like /writing/*) to /api/... function endpoints.

If those functions are publicly reachable (directly or via rewrites), then any repeated HTTP requests (including crawlers/bots/social preview systems/scanners) could trigger backend function executions and therefore drive compute charges.

So from an architecture perspective, your “requests triggering Functions execution” chain makes sense. What’s missing in the provided documentation is an explicit statement that Static Web Apps managed Functions execution time billing will spike primarily due to crawler/bot traffic in exactly this way—so we can’t definitively validate that portion here.

2) Is “Functions → Standard Execution Time” the expected meter?

From the scenario description, it matches what you would expect if the billed work is indeed function executions. Also, your own Cost Analysis indicates the increase maps to the Functions category and specifically to Standard Execution Time, which strongly suggests the meter is correctly attributing usage to Function executions rather than (for example) app hosting runtime.

Again, the provided docs don’t explicitly map this meter to Static Web Apps route-rewrite behavior, but your observation aligns with the intended billing model of serverless execution.

3) Should your planned deployment changes stop the charges?

Your proposed mitigation is reasonable:

Set api_location to empty so Static Web Apps won’t deploy/host the local api/ folder as managed Functions.

Remove rewrites that route SPA paths to the /api/... function endpoints.

If those changes prevent the functions from being deployed (or prevent routing traffic to them), then future requests shouldn’t produce function execution charges going forward.

However, you may still see:

Charges that were already incurred earlier in the month (including invoice finalization effects), and/or

Billing/cost attribution adjustments that appear on the invoice after the fact

So you should expect the biggest improvement after the deployment is applied and enough time passes to cover the next billing window.

4) Billing review / escalation guidance (what to do if you still see the spike after the fix)

The documentation provided includes guidance for creating a billing/usage disagreement support request and links to workflows for investigating unexpected charges.

A good practical next step is to open a billing-related support request and ask for:

Confirmation of how the Functions executions were attributed to the Static Web App

Review of the invoice line items tied to the Functions → Standard Execution Time meter

Verification that after your fix, Function execution ceased for the affected routes

If the issue involves retroactive changes or unexpected attribution, Microsoft support can review invoice details.

Here are the steps you can follow to create support requests:

Go to Azure portal > Search for Help + Support or https://portal.azure.com/#view/Microsoft_Azure_Support/HelpAndSupportBlade/~/overview

Click on Create a Support Request.

On right-side panel, enter Billing and click Go > select the issue with "Billing" > select your Subscription then click Next.

Do not click on any suggested articles instead click on the Create support request on top of the panel.

Select the Issue type as Billing and, select the summary, problem type and problem subtype as per your issue like below > then click on Next.

Do not click any recommendation solution/article, instead click on the Return to support request then click Next.

Fill all the required information and provide a clear description of your issue and click Next.

Review and create as submit the support request.

You should receive an automated email within a few minutes and then be contacted by support team.

Kindly check the below documentation for more details: How to create an Azure support request - Azure supportability | Microsoft Learn

References (provided documentation)

Azure Static Web Apps (overview & troubleshooting/support boundaries)

Azure Static Web Apps (Application Insights support boundaries)

Investigate unexpected cost increases (Log Analytics example—pattern for identifying cost spikes)

Hope this helps! If you encounter any issues, please reach out to us. Thanks.
Bharath Y P 9,645 Reputation points Microsoft External Staff Moderator

2026-06-12T05:52:39.5333333+00:00

Hello Sanjay, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!

2 answers

Your answer

Bharath Y P 9,645 Reputation points Microsoft External Staff Moderator

2026-06-12T05:52:39.5333333+00:00

Hello Sanjay, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!

Answer 1

The technical behavior described is consistent with how Azure bills execution-based services, but the provided context does not explicitly cover Static Web Apps–hosted Functions or their exact meters. Only the following billing-related points are supported by the context:

Execution-based meters can drive large cost spikes
The context shows that:

Azure Functions on consumption plans are billed based on execution counts and execution time, using metrics such as Function Execution Count and Execution Units that map to execution-time meters.
Invoices and Cost Analysis expose these meters as part of the Compute category and allow drilling down to the meter level.

From the Functions billing documentation:

Metrics like OnDemandFunctionExecutionUnits and AlwaysReadyFunctionExecutionUnits are converted into GB-seconds and billed as execution time.
These metrics are directly tied to the Execution Time meters for Functions.

This supports that a high volume of function executions (for example, from HTTP-triggered endpoints) can generate significant compute charges under a Functions execution-time meter.

Cost analysis is the correct way to validate which service and meter caused the spike
The context describes how to:

Use Cost analysis to identify which services and meters caused unexpected cost increases.
Group by Meter category and drill into specific services (for example, Log Analytics, Azure Grafana, Microsoft Sentinel) to see which meter drove the spike.

Applied to this scenario, the supported guidance is:

Use Cost analysis on the subscription and filter to the Static Web App resource.
Group by Meter category and then by Meter to confirm that the Functions → Standard Execution Time meter is responsible for the spike.

Unexpected or anomalous charges should be investigated with Cost Management tools and then escalated to support
The context provides a general process for unexpected charges:

Review the invoice and correlate it with Cost analysis.
Identify the specific services and meters causing the spike.
If the cause is still unclear or if there is a billing dispute, create an Azure support request for billing.

The context also notes:

Azure does not log all user actions; billing is based on resource usage. If logging wasn’t enabled at the time of the spike, it might not be possible to reconstruct the exact traffic pattern.
When unexpected costs are identified and cannot be fully explained or controlled via configuration alone, the next step is to open a billing/support case.

Billing disputes, retroactive adjustments, and credits must be handled by Azure Support
The context includes multiple Q&A examples where:

Users experienced unexpected or retroactive billing increases.
Moderators consistently directed them to create billing support requests via the Azure portal.
Billing support is explicitly stated as free, and support engineers can review and address billing disputes.

From these examples, the supported guidance is:

For any request involving credits, refunds, or goodwill adjustments (including cases where configuration misunderstandings caused unexpected usage), the only supported path is to open a Billing support request in the Azure portal.
Community forums and documentation cannot grant or commit to credits; only the billing support team can review the account, usage, and policies and decide on adjustments.

How to proceed in this case, based on supported guidance
Within the limits of the context, the following steps are supported:
Validate the meter and service in Cost analysis
- In the Azure portal, open Cost Management + Billing.
- Use Cost analysis for the subscription.
- Filter to the Static Web App resource and group by Meter category and Meter to confirm that Functions → Standard Execution Time is the primary driver of the May compute charges.
Check for anomalies and confirm that the spike is limited to the period in question
- Use daily cost views (similar to the Log Analytics example) to identify the exact dates where the spike occurred.
- Confirm that after the configuration changes are deployed, daily costs for that meter drop or disappear.
Enable or review logging/metrics for future validation
- Ensure that appropriate logging and metrics are enabled for Functions and Static Web Apps so that future spikes can be correlated with traffic and execution patterns.
Open a billing support request for review/credits
- Create a Billing support request from the Azure portal.
- Provide:
  - Subscription ID.
  - The Static Web App resource name.
  - The time range and invoice details (April vs. May charges).
  - Screenshots or exports from Cost analysis showing the Functions → Standard Execution Time meter as the cause.
  - A description of the configuration (routes and api_location) and the corrective changes already applied.
- Request a review of the unexpected usage and ask whether any adjustment or credit is possible.

The context does not state any general policy or guarantee that credits will be granted for misconfigurations, so any decision about credits or goodwill adjustments must come from the billing support team after reviewing the specific subscription and usage history.

References:

Answer 2

Sahil Kumar 0

Check Azure Cost Analysis and Azure Function metrics (execution count, duration, and scaling). A sudden increase in any of these can cause a large billing spike. If the usage seems unexpected, contact Microsoft Billing Support for investigation.

0 comments

Share via

Unexpected Azure Bill Increase (₹30k → ₹5.16L) Due to Azure Functions Behind Static Web App – Seeking Root Cause Validation and Billing Guidance

Static Web App Route Configuration

Our Understanding

Planned Fix

Questions

2 answers

Your answer