WebServices HTTP RawLogs no longer populated.

Thank you Shree Hima, for your response.

"Azure App Service uses file system-based logging, which has a 100 MB limit. When this limit is reached, the oldest logs are deleted to make room for new ones...
If you need to keep logs for longer than this rolling limit,..."

Yes - I am aware of the 100 MB limit.

No, we do NOT need to keep logs longer than this rolling limit. (In fact, our system would be downloading any logs via FTP several times daily.)

The problem was NOT that older logs were being deleted on 08/15 (because of size). On 08/15, the logging stopped and no more entries were written to the log files.

To rule out a potential quota limit, we waited a few days - and when logging never resumed, WE manually deleted the existing log files from the file system. However, even after with the logging directory now empty (as you saw in my previous screen captures), and even after restarting the app service, and even after resetting the settings, logging never resumed.

Furthermore, there is a second app service affected the same way. That second app service has minimal daily web traffic - so the log files were comparatively small. Logging for that second app service stopped the exact same moment. It is extremely unlikley that two different app services with grossly different logging volume would exceed the same 100 MB limit at the exact same moment!

So - the task for the Azure tech experts is, to find out what "broke" in Azure on 08/15.

Because our web statistics reporting package uses an automated, simple FTP process we can't customize, we intentionally are using the file system storage.

We just ran into the same issue in one of our production services, but it is even more perplexing. In an App Service which is scaled to 2 servers, only 1 of the 2 servers is writing successfully to rawlogs. It seemed to have broken on 3/10/26 around midnight, where with no changes to the application deployment, now only one of the two instance log files is being generated. No amount of restart, refresh, code deployment, VIP swap or turning on/off the Application logs seems to fix it. I've switched between Off, File System, Blob storage for logging. No change. Only one of the two instances is generating log files. How are we supposed to diagnose and fix this?

Okay - so they have a systemwide problem.
Our logging had started working again last year, after it had stopped for about a week. I don't know if someone at Microsoft had stumbled over something and took some action to "reset" stuff, or if there was some other factor.

And now, just like with you, on 3/11/2026 the problem started again. I already had tried restarting the servers, had tried to toggle the W3C logging on and off, etc. - at no avail.

I'm sorry about your issue, of course - but also glad you reported it here, because now we finally have validation that it's not limited to one customer or our specific AppService(s).

My AppService is hosted in the zone "Germany West Central" - how about yours?

Interesting, thanks for your response. We are hosted in "North Central US".

Actually looking into more detail it occurred roughly 3/9/26 3:30 PM EST (UTC-4). Around that time the logs rotated instance names so it looks like there was some sort of backend system update that affected one of our two instances, and the non-rotated instance stopped logging a few minutes later. Basically where I would normally see 2 raw log files per hour, I see 3 log files during that hour, then only 1 log file after.

I have also put in a support request through our Azure support provider so see if this can be escalated further since we rely on those logs for troubleshooting of unauthorized activity and it's pretty critical to have 100% visibility.

I will try to keep updated if I hear anything more!

As of about an hour ago, it does look like this has fixed itself on my end - I'm seeing the two log files generated per instance per hour again. I took no action on my part and was not able to get Azure support involved either because of technical issues with our vendor. So it would seem some backend update has once again automatically resolved this issue, with no acknowledgment on the part of Azure/Microsoft, and no clear explanation as to cause or fix for this issue, or whether it can be prevented in the future.

Unfortunately, no such luck for me. (Been checking a few times since your message in case there was some slight regional delay)

We have noticed this issue since 19th March Australian EST. Still no resolution.

I spoke too soon on my end too, the log files were working for about 3-4 hours then stopped again, and now currently only seeing 1/2 of files being generated. I am working on escalating a support case through our managed provider.

Thanks, Kurt - I had seen this "flickering" a few days after the problem started.

And, today, I suddenly saw stats come in for a blip, then pause again, then seemed almost normal an hour ago, but since then it seems "light" again.

I figured I share my "parallel" experience in case it informs your support provider to the generic/worldwide nature of this problem.

Yesterday (26 Mar 2026) around 4 PM EDT logging seems to have resumed and so far has been running for 16 hours.

Andy - Interesting that it is working for you now. I am still seeing as of last hour, only generating 1/2 of the expected log files on our end.

I've started to have contact with a support engineer @ Microsoft but so far they are just doing initial information gathering. They gave one generic suggestion which I might try this weekend - to briefly scale up/down the app server to force migration to new instances, which may clear whatever condition is happening on the current instance. I do see that we have other servers that are not affected by this issue so maybe it will have an impact.

Hi - I'm grateful that you're working with support. Because if they never get to the bottom of this and it just mysteriously works again, then we'll be in the same boat in a few weeks or months.

I have my instances recycle on a regular basis, typically at minimum daily. Last time, I went through various attempts to reset, reboot, recycle -- even turning logging on and off. None made a difference.

Instances also wouldn't explain why the problem surfaces quasi-simultaneously with (at least) 3 different customers in different regions - and seems to recover around the same day.

I have not received any updates yet from the Azure support engineer - however I did attempt their suggested workaround (changing the scale settings for the app), where I upsized it from P2v3 to P3v2 server - which was a good idea anyway. It has been 2-3 days since I made this change, and the IIS web logs do appear to be working consistently since then. So I guess that is a valid solution in the future - hopefully they can identify the actual root cause and prevent it, but I'm not too hopeful with the sporadic nature of it.

Thanks Kurt - in my case, I never upsized to a different server.

I have been given the following resolution response from an Azure engineer:

Hello Kurt,

Thank you very much for your patience while we investigated this further.

I wanted to share an update now that the Azure App Service Product Group has confirmed the root cause and validated the mitigation of this issue

What happened:

The behavior you observed was caused by a recent platform change. A MiniYarp rollout introduced a defect in the App Service platform’s Resource Metering Service that affected how web server logging was initialized on already‑running worker instances. In this state, a worker could continue serving production traffic but stop emitting Web Server HTTP logs to File System or Storage.

This explains why your app continued to function normally, why only one instance was emitting logs at times, why the specific log file names changed as backend workers rotated, and why restarts, redeployments, and slot swaps did not consistently resolve the issue.

This was a platform‑side issue and was not related to your application code, configuration, or logging settings.

Mitigation and current status:

Once the issue was identified, the Product Group initiated a rollback and mitigation plan. This included rebooting affected worker instances to restore proper log initialization. Your scale‑up / scale‑down action effectively forced a worker reallocation, which is why logging behavior returned to normal.

At this point, the issue is considered mitigated across the majority of the platform, and monitoring is ongoing to ensure any remaining affected workers are corrected.

Looking ahead:

The Product Group is now fully aware of this failure mode and has identified the specific cause. They have addressed the issue by performing the rollback and are working to improve both prevention and detection going forward to allows the team to respond more quickly should a similar condition reappear.  If you notice any recurrence of missing web server logs or related behavior, please let us know immediately and we can engage the platform team again with full context.

Thank you again for the detailed data you provided throughout the investigation, it materially helped drive this to resolution.  Please let me know if you have any questions or if we can assist you further.

Regards,

name removed

Azure App Services Support Engineer