HubSpot was unavailable to many users in North America for 2h 55m on 23 October 2026. HubSpot traced the fault to a Cloudflare outage and underlying network connectivity issues on its own side, not to anything in your account or setup.
Started
16:07 UTC
Duration
Lasted 2h 55m
Source
IsDown
Next time
HubSpot is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Sales Tools, Reports, Integrations, Mobile, HubSpot APIs, CRM, Website, Chat & Automation, Service Tools, Marketing Tools
What happened?
The incident started at 16:07 UTC, which HubSpot's status page logged as 11:28 AM EDT. HubSpot's first update named the cause directly, linking to a Cloudflare status page incident and saying it was working with Cloudflare to resolve the issue. Ten components were listed as affected: CRM, Marketing Tools, Website, Sales Tools, Service Tools, Chat & Automation, Reports, HubSpot APIs, Integrations and Mobile, which covers most of the platform rather than one isolated tool. At 16:32 UTC HubSpot moved to monitoring, saying it had addressed the issue and was watching performance to make sure tools recovered properly. The resolution came at 18:55 UTC, with HubSpot stating the window ran from 11:28 AM to 2:43 PM EDT and that "many customers in North America experienced issues accessing HubSpot.com and various tools." HubSpot attributed this to underlying network connectivity issues, a slightly different phrase from the Cloudflare reference in the first update, and did not reconcile the two in its final note. The resolution update also mentions a post-incident review without giving a date or link for when that review, or its findings, will be published. No user reports were filed during the window on this page's record, so there's nothing from your own account activity to compare against HubSpot's account of impact. This was one incident across the day, lasting 2h 55m from first report to resolution, with three updates published in total.
Learning
When a vendor's incident traces back to a third party like Cloudflare, the vendor's own status page is often the only account you get of what actually failed, since the fault sits outside your product and outside anything your own endpoint checks would catch. A connectivity problem between HubSpot and Cloudflare, or inside Cloudflare's network, can make HubSpot.com and its tools unreachable for users in a whole region while your own integration code, API calls and webhook listeners show nothing wrong, because the layer that broke is the delivery path, not your logic. This is why relying only on your own uptime checks for a dependency like this leaves a blind spot: your checks confirm your half is fine, but they can't see a routing or network fault happening upstream of your traffic. HubSpot's three-update timeline here, with 25 minutes between the first two and over two hours before resolution, shows how long such a dependency fault can run before a vendor calls it closed, and this one has 13 incidents logged in the last 90 days with a median duration of 1 hour 54 minutes, so this kind of thing recurs. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
