Changelog

A saturated instance answers a health check in 3 to 10 seconds where a healthy one takes 9 to 225 milliseconds, and both used to read as fine. Slow now reads as degraded, carrying the instance's own reason, so we see the problem while it's still one slow server and not yet your failed request. Auto is watched too, with limits set to how long a real hard solve takes instead of a generic one that would fire on every success.

The profile parameter tells the unblocker which browser to look like on /api/single and /api/proxy. Pass an exact profile id (like firefox147 or chrome146), or let browser + os + version resolve to the newest matching combination. GET /api/profiles returns the current catalogue (79 profiles across five browser families), so you don't hardcode a list that goes stale. The Dashboard playground exposes the same picker as three cascading selects.

The Dashboard Playground now has three cascading selects for OS, browser, and version, pulled live from the profile catalogue. Pick any two and the third narrows to whatever actually resolves. Choosing a profile turns unblocker on, because the API refuses a profile without it.

A service now counts as down only when it has lost every instance, the one state where your request has nowhere to land. Routine rolling deploys no longer show up as incidents on the status page.

The default signature the unblocker sends is now a current major, not the old one scrapers hardcoded. Sites that had started returning static block pages to older majors return their real page on Single and Browser. Both products moved together, so a cf_clearance replay from Browser to Single still lands byte-for-byte.

When your bank asked for 3D Secure on a plan upgrade, the request would poll for a change that never arrived (nobody had prompted you to authenticate). The change-plan flow now handles the extra step like the first subscribe does, so the upgrade goes through.

If an admin assigns you a custom plan, it now shows up in Billing / Plan as 'Your custom plan: {name} ({price})' with a button to subscribe. Before this, the assignment sat invisible until someone told you it existed.

Browser used to charge the 30-credit defense-solved tier only when a Cloudflare clearance cookie showed up. Now it does the same for any defense we recognise and clear, starting with SiteGround. The response also carries defenses: { present, cleared }, so you can tell which vendor was in the way even when we haven't beaten it yet (DataDome, PerimeterX, Akamai, Incapsula and hCaptcha are recognised for now, not yet cleared).

Browser responses now return defenses: { present, cleared }: every vendor the target ran, and every one we actually cleared. Billing follows the same rule. A request that clears any vendor (not only Cloudflare) is a defense solve, and vendors we recognise but can't yet beat show up in present and never raise the price.

SiteGround fronts a large chunk of small WordPress and WooCommerce shops, so its Robot Challenge Screen is a class of targets, not one site. With unblocker: true, Single now solves it in-process and returns the real page. Before this, you had to bring up Browser for that class of target, which meant paying for a browser session and the wait. The clearance cookie comes back in the response, so a replay stays cheap.

Browser now handles a challenge page that redirects before its body can be read, so requests to protected sites come back with content instead of an empty response.

SiteGround puts a 'Robot Challenge Screen' in front of a lot of small WordPress and WooCommerce shops; there's nothing to click, it's a SHA-1 proof of work. Single now clears it in one call and returns the real page, at 2 credits instead of a 30-credit browser session. It's the first non-Cloudflare defense Single handles on its own.

When you send a header on Single or Proxy requests with the unblocker on (default), your value now reaches the origin as sent. Common headers like Accept and User-Agent could go out twice, and some upstreams picked the wrong one. If you noticed Accept: application/json coming back as XML, or a pinned User-Agent not being honored, that's fixed.

If you pass exitCountries and your plan doesn't include geo targeting, you'll get a 403 that names the parameter and points to the fix. No more guessing which field on the request tripped the check. Plans that do include geo targeting are unaffected.

The plan compare table now has a bandwidth row. Every public plan comes with unlimited bandwidth, so egress won't quietly eat your budget as your traffic scales. Custom plans show their exact GB figure when they're capped.