Date: July 14, 2026 Duration: ~7 hours (12:07–19:19 UTC) Severity: Major
A third-party outage at Help Scout, the provider that hosts our Help Center at support.buffer.com. Their Docs hosting infrastructure had an issue that prevented origin servers from responding, which Cloudflare (sitting in front of the site) surfaced as SSL handshake failures and connection timeouts. Help Scout confirmed the issue on their own status page and resolved it on their end at 19:00 UTC.
For about seven hours, the Help Center at support.buffer.com was unreliable. Depending on when someone visited, they might have seen a 404 error, a Cloudflare error page, a very slow load that eventually failed, or the site working normally — the problem was intermittent rather than a clean, total outage the whole time. Both the homepage and individual articles were affected. No other Buffer products or services were impacted; this was isolated to the Help Center.
We confirmed within minutes that the issue was on Help Scout's side, not ours (no recent changes on our end, DNS still pointed correctly).
We opened an incident on our status page early so customers had visibility while we investigated.
Since the root cause was out of our hands, our role was to monitor Help Scout's status page, track their progress, and keep our own status page updated as things changed.
We deliberately kept the incident open through a period where things looked recovered but weren't fully stable yet, waiting until Help Scout confirmed their fix before considering it resolved.
Once Help Scout marked their incident resolved and we confirmed the Help Center was stable again, we closed ours out.
We detected it before most customers did. A team member noticed the outage and we had it under investigation before the first support ticket came in, which is the outcome we want even though detection was manual this time.
We should have automated, proactive monitoring for the Help Center. There's currently no automated check that would catch this kind of outage on its own — we're adding one.
Waiting for the third party to confirm full resolution — not just apparent recovery — was the right call. The site looked fine at one point mid-incident, then degraded again. Treating "looks okay" and "provider confirms resolved" as different bars is now something we'll apply to future third-party incidents.
Our error page didn't show our own status updates. When Help Scout's origin was completely down, the status banner we normally show on Help Center pages couldn't load, because it's injected by Help Scout itself. We're looking at adding that messaging directly to our own fallback error page so customers still get useful information even when the underlying provider is fully down.
Relying entirely on a third party for resolution is a real constraint. We have no direct lever to fix an outage on a vendor's infrastructure — only to monitor, communicate, and wait. This is a good reminder to factor provider reliability and status-page responsiveness into how we choose and evaluate tools we depend on.
