HubSpot: Some tools are slow to load or timing out
Cloudflare outage, Dec 16, 2021 · 10 vendors, 10 incidents
HubSpot’s incident blames Cloudflare as the cause. (hop 1, posted +0 min vs the first vendor naming Cloudflare)
“…loading or timeout issues in HubSpot due to an outage on our third-party cloud platform, Cloudflare. Cloudflare has resolved the root cause of the issue, and all tools in HubSpot should now load prop…”
Swipe sideways to see the whole diagram.
Mermaid source
flowchart LR
root["Cloudflare<br/>own incident not archived"]:::inferred
h1["Within an hour<br/>2 vendors, 2 blamed Cloudflare<br/>HubSpot, Optimizely"]:::blames
root --> h1
me["HubSpot (this incident)<br/>posted +0 min"]:::me
h1 --- meFull event: timeline, evidence and all vendors →
Detected automatically from incidents that started together and named the same provider. A link means one vendor’s incident named another, not a confirmed cause.
Timeline of updates
- resolved
Between 3:27 PM and 3:46 PM EST, some customers had loading or timeout issues in HubSpot due to an outage on our third-party cloud platform, Cloudflare. Cloudflare has resolved the root cause of the issue, and all tools in HubSpot should now load properly. You can follow the issue here: https://www.cloudflarestatus.com/incidents/qz5m74q8q0jl.
From HubSpot’s published incident history: for incidents before Rewindex began polling this status page, only the final update text is available.
Archive proof
Rewindex commits each version of an incident it captures to a daily checkpoint, chains it to the day before, and has the checkpoint timestamped by FreeTSA and DigiCert.
How the archive is checked, and what it cannot prove.
This incident predates live tracking (October 17, 2026). It came from the vendor’s own published history, which is not covered by checkpoints.
Impact, status and times are the vendor’s own, as last archived. View on status.hubspot.com (opens in new tab).