Scrapfly experienced a minor incident on May 21, 2026 affecting Cloud Browser, lasting 2h. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- identified May 21, 2026, 01:44 PM UTC
CDP command in question. Page.getRenderedContent, the Scrapium-custom CDP method our Cloud Browser uses to capture the final, post-JavaScript-rendered HTML of a page. It also inlines OOPIF iframe content into the parent document. This is the primary content-retrieval path used by the Scrapfly scrape pipeline, the Cloud Browser API, and any customer SDK call that returns rendered content. Area of impact. Scrape jobs targeting JavaScript-rendered pages whose rendered HTML contains three or more non-ASCII characters. In practice this covers most German, French, Spanish, Portuguese, Italian, Cyrillic, Greek, Chinese, Japanese, Korean, Arabic, and Hebrew pages. Pure-ASCII pages are not affected. Customers using direct CDP (DOM.getOuterHTML, Runtime.evaluate) are not affected. Issue and regression. A UTF-8 mojibake-recovery heuristic, added to repair pages whose servers misdeclare their charset, became overly broad. It now matches the byte signature of any UTF-8-encoded accented or non-Latin character and triggers a fall-back to the raw HTTP body. That fallback discards every DOM mutation the page's JavaScript made (SPA hydration, dynamic content insertion, framework rendering). Affected scrapes receive the empty pre-hydration page shell instead of the rendered listing, article, or product detail. A fix is in progress and being validated against our German, French, Cyrillic, and mixed-encoding regression tests before rollout to the Cloud Browser pool.
- monitoring May 21, 2026, 03:12 PM UTC
The fix is currently deployed on the browser fleet
- resolved May 21, 2026, 03:44 PM UTC
We have enriched our test suite with new heuristics discovered to ensure correct validation on QA