While investigating a support case for one of our clients running Sitecore XP 9.2 on Managed Cloud Standard, we started seeing intermittent HTTP 408 errors in Application Insights. Publishing jobs were failing silently — items looked queued but never actually went live. Over 200 errors appeared in a 30-day window and there was no obvious slowness on the Publishing Service side.
We opened a support case with Sitecore and the initial response was that there was no clear root cause identified. It took some digging before the actual cause surfaced — and it turned out to be a publicly known ASP.NET Core bug. This post walks through what we found, what we tried, and what the actual fix is.
What we were seeing
The errors were surfacing through the Sitecore Services Client (SSC) API when polling job status:
Refit.ApiException: Response status code does not indicate success: 408 (Request Timeout).
ERROR [Sitecore Services]: HTTP GET
URL: https://your-cms.example.com/sitecore/api/ssc/publishing/jobs/{GUID}No obvious slowness in Publishing Service instance metrics. No user-facing error message. Just content that was never published.
Root cause: Kestrel's MinRequestBodyDataRate
The error originates inside the Kestrel web server (ASP.NET Core) that hosts the Sitecore Publishing Service. When the CMS sends a large manifest or request body to SPS and the transfer rate is too slow or exceeds the configured read timeout, Kestrel aborts the connection.
The stack trace confirmed it:
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException:
Reading the request body timed out due to data arriving too slowly.
See MinRequestBodyDataRate.
at Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw(RequestRejectionReason reason)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1ContentLengthMessageBody.ReadAsyncInternal(...)This is a known ASP.NET Core issue tracked publicly on GitHub — dotnet/aspnetcore issue #4707. There is also a related Stack Overflow thread with more context. The issue was actually referenced in the Sitecore Support response we received, which confirmed this is the root cause. It gets triggered by a combination of things: large publishing manifests (many items at once), network latency between the CMS and Publishing Service, and low default Kestrel rate limits in the older .NET Core version used by SPS pre-7.0.
How to diagnose it
First, filter Application Insights for 408 status codes on both your CM and Publishing Service app resources. Look for patterns — time of day, volume of items being published, correlation with deployments or content migrations.
Second, if your logging levels for Root and Sitecore.Diagnostics.Publishing are set to WARN or ERROR, you will miss a lot. Temporarily set both to INFO:
<!-- Sitecore log config (e.g. log4net) -->
<logger name="Root" level="INFO" />
<logger name="Sitecore.Diagnostics.Publishing" level="INFO" />This surfaces publishing options, manifest sizes, and job creation details that are otherwise invisible.
Third, look in the Publishing Service logs for the specific Connection id and Request id pattern:
[Error] Connection id "0HNLEBE7F0UO6", Request id "0HNLEBE7F0UO6:00000007":
An unhandled exception was thrown by the application.Cross-reference those timestamps with your CMS publish events.
Interim workarounds
We tried a couple of things while the actual fix was being planned.
One option is increasing maxAllowedContentLength in the SPS web.config:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483648" />
</requestFiltering>
</security>
</system.webServer>Important caveat: this raises the IIS-level filter but does not touch the Kestrel MinRequestBodyDataRate timeout — the actual source of the 408. It helped a bit but did not fully resolve the problem.
Another option is reducing batch sizes for large publishes, which reduces the manifest payload per request. Again, this reduces frequency but does not eliminate the issue.
The actual fix: upgrade Sitecore Publishing Service
The root fix is upgrading SPS to version 7.0 or 8.0, which is built on a newer .NET Core runtime where the Kestrel body rate issue is resolved. Sitecore Support explicitly recommended this path for our case.
Sitecore Support confirmed in a follow-up response that upgrading Sitecore software — including the Publishing Service — is the customer's responsibility on Managed Cloud. They referenced the Managed Cloud roles and responsibilities documentation for the full breakdown of what Sitecore manages versus what falls to the customer.
They also shared the SPS compatibility table, which confirmed that Sitecore XP 9.2 is compatible with Publishing Service up to version 8.0. So the upgrade path is available — you just need to plan and carry it out yourself.
It is also worth mentioning that Sitecore XP 9.2 (Initial Release) is significantly out of mainstream support. A full platform upgrade to a supported version — or migration to XM Cloud — would resolve this and many other legacy constraints. That is a longer conversation, but it should be on the roadmap if you are still running 9.2.
Summary
The 408 errors are caused by Kestrel's MinRequestBodyDataRate timeout killing connections when large publish manifests arrive too slowly. It is a publicly known ASP.NET Core issue, and the permanent fix is upgrading the Sitecore Publishing Service to v7.0 or v8.0 — both are compatible with XP 9.2. The upgrade is customer responsibility on Managed Cloud Standard, not something Sitecore will do for you. Interim workarounds like reducing batch sizes and raising the IIS content length limit can reduce the frequency, but they do not fix the root cause.
If you are hitting this, open a support case, check the compatibility table, and start planning the upgrade.
