Hi,

The 95 seconds is the limit ODC puts on any external logic (custom code) call, and PrintToPDF runs as external logic. It starts a headless browser, opens your print screen URL, waits for it to finish loading and then renders the PDF, and all of that has to fit in 95 seconds. With 2 failures out of 400, the PDF itself is rarely the problem. Usually something was slower on those two runs. What I would check:

1. Cold start. If nothing called it for a while, the first call has to start the browser from scratch, which costs extra seconds. See if the two timeouts were the first calls after a quiet period.
2. The data on the print screen. Every aggregate or data action there runs while the browser is waiting. If those two runs were for records with much more data (long lists, many images), the page simply took longer. Keep the print screen light and fetch only what gets printed.
3. External resources like fonts, images or scripts from outside URLs (Google Fonts, a CDN, images on another server). If one of them hangs, the page never finishes loading. Better to have them inside the app.
4. Many PDFs generated at the same moment, competing for the same resources.

Since it’s rare, I would also add a retry. Catch the exception, save the request with a status and an attempt counter, and let a timer or a new event try it again later, up to 2 or 3 attempts. That way the occasional timeout becomes a small delay instead of an error.