An Azure service that provides an event-driven serverless compute platform.
Hi @Pea Creamer ,
It looks like the root cause here was the Y1 (free/consumption-like) App Service plan being removed unexpectedly from your tenant. When that plan vanished on May 6th, your Function App had nowhere to run, so it went down until you re-provisioned on P2V3. Moving to P2V3 was the right call, but to be extra sure you won’t run into a similar surprise, here’s what I’d recommend:
- Migrate to a supported App Service SKU
- Use at least a P1V3/P2V3 (or Premium/Elastic) plan. These SKUs won’t be removed without plenty of warning.
- Turn on Always On in Platform Features so your host stays warm and you avoid cold starts.
- Monitor and size for memory usage
- Error codes 134 and 137 mean your process was OOM-killed. In Kudu you can inspect memory spikes under D:\home\LogFiles\Application\Functions or via Performance Counters in App Insights.
- In Application Insights, try a query against performanceCounters to see memory trends:
performanceCounters
| where counterName == "\Process\Private Bytes" and timestamp > ago(1d)
- Keep your runtime supported
- You’re already on Functions Runtime v4 - perfect. If you ever need to change it, go to Configuration > Function runtime settings.
- Use Application Insights and Activity Log for deep debugging
- To catch host-level restarts or config changes, run:
traces
| where message contains "Host configuration has changed" or message contains "Signaling restart"
- To surface errors at the outage time:
traces
| where timestamp between (datetime(2023-05-06T00:00:00Z) .. datetime(2023-05-06T01:00:00Z))
| where severityLevel == "Error"
- Configure autoscale if your webshop has traffic bursts
- In your App Service Plan, set scale-out rules based on CPU or memory thresholds to add instances before you hit OOMs.
Hope this helps!
If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.