PDF Rendering Timeouts on Linux AKS
After upgrading, HTML-to-PDF jobs on a resource-constrained Azure Kubernetes Service (AKS) Linux container slow down sharply and eventually fail. The renderer throws a timeout partway through the job:
IronPdfNativeException: Timeout after 65s while rendering pdf from html
By default, IronPDF renders HTML to PDF with a multithreaded Chrome process model. In a constrained AKS pod with fixed memory limits (for example, 6Gi requests and limits) and no custom render tuning, that threading model competes for the limited resources, pushing render latency up until jobs time out. Because ChromeBrowserLimit was left at its default, the renderer was never told to respect the container's actual capacity.
Solution
1. Enable single-process rendering
Run the Chrome renderer in a single process instead of spawning multiple threads. SingleProcess is a static property on the Installation class, so set it once at application startup, before any rendering takes place:
IronPdf.Installation.SingleProcess = true;
IronPdf.Installation.SingleProcess = true;
IronPdf.Installation.SingleProcess = True
Installation.SingleProcess = true collapses the renderer onto one process, which cuts the threading overhead that a tight container cannot absorb. Note that IronPDF documents this setting as experimental and less stable under heavy load, so validate it against your workload before relying on it in production.
2. Redeploy and confirm
Redeploy the containerized service, then watch rendering latency and timeout rates to verify the regression is gone.
3. Tune ChromeBrowserLimit if timeouts persist
Should jobs still time out after switching to single-process mode, set ChromeBrowserLimit to match the pod's real memory and CPU allocation rather than leaving it at the default.

