Skip to main content
Buffer logo

Is Buffer Down?

No — Buffer is up
Buffer's status page
Operational · no open incidents
FlareWarden checks
Website reachable · 8 of 8 regions · 444 ms

Right now

The verdict is the worse of these two. How we decide

Buffer's status page

status.buffer.com · read · checked every 3 minutes

Operational
Buffer's components, as its status page reports them
ComponentStatus
LoginOperational
Channel connectionsOperational
PublishingOperational
AnalyticsOperational
CommunityOperational
SettingsOperational
InstagramOperational
FacebookOperational
ThreadsOperational
LinkedInOperational
XOperational
BlueskyOperational
7 more, all operational · show all 19
All of Buffer's components
ComponentStatus
LoginOperational
Channel connectionsOperational
PublishingOperational
AnalyticsOperational
CommunityOperational
SettingsOperational
InstagramOperational
FacebookOperational
ThreadsOperational
LinkedInOperational
XOperational
BlueskyOperational
YoutubeOperational
TikTokOperational
MastodonOperational
PinterestOperational
Google Business profileOperational
Buffer APIOperational
Buffer MCPOperational

FlareWarden checks

buffer.com from 8 regions · when you open this page (at most every 30 minutes), otherwise every 6 hours

Reachable
Regions up
8 of 8
Response
444 ms
Checked

By region

  • Amsterdam reachable, 519 ms
  • Chicago reachable, 110 ms
  • Paris reachable, 448 ms
  • San Jose reachable, 349 ms
  • Singapore reachable, 376 ms
  • Stockholm reachable, 194 ms
  • Sydney reachable, 1317 ms
  • Toronto reachable, 242 ms
Timing by region
Connection timing for each region that loaded the page
RegionDNSTCPTLSTTFB
Amsterdam54 ms3 ms13 ms454 ms
Chicago26 ms1 ms13 ms104 ms
Paris20 ms2 ms11 ms372 ms
San Jose57 ms2 ms20 ms281 ms
Singapore75 ms1 ms12 ms370 ms
Stockholm26 ms2 ms12 ms188 ms
Sydney103 ms1 ms12 ms1080 ms
Toronto77 ms1 ms11 ms225 ms
We check that buffer.com loads, not every feature behind it. Test it yourself

History

Incidents Buffer reported

Since Oct 22, 15 days · from status.buffer.com

Incidents
3
Major or critical
3
Median to resolve
11m
  1. lasted 55m
  2. Issue with [Feature]

    major ·

    lasted 10m
  3. Degraded Performance

    major ·

    lasted 11m

Buffer website availability

Measured by FlareWarden · buffer.com

Last 7 days
100%
Last 30 days
100%
Last 90 days
100%
Avg response, 30 days
684ms

Last 30 days

91-day clean streak
Oct 7: 100.00% uptime, 32 checks
Oct 8: 100.00% uptime, 32 checks
Oct 9: 100.00% uptime, 32 checks
Oct 10: 100.00% uptime, 32 checks
Oct 11: 100.00% uptime, 32 checks
Oct 12: 100.00% uptime, 32 checks
Oct 13: 100.00% uptime, 32 checks
Oct 14: 100.00% uptime, 32 checks
Oct 15: 100.00% uptime, 32 checks
Oct 16: 100.00% uptime, 32 checks
Oct 17: 100.00% uptime, 29 checks
Oct 18: 100.00% uptime, 32 checks
Oct 19: 100.00% uptime, 32 checks
Oct 20: 100.00% uptime, 32 checks
Oct 21: 100.00% uptime, 32 checks
Oct 22: 100.00% uptime, 32 checks
Oct 23: 100.00% uptime, 32 checks
Oct 24: 100.00% uptime, 32 checks
Oct 25: 100.00% uptime, 32 checks
Oct 26: 100.00% uptime, 32 checks
Oct 27: 100.00% uptime, 32 checks
Oct 28: 100.00% uptime, 32 checks
Oct 29: 100.00% uptime, 32 checks
Oct 30: 100.00% uptime, 32 checks
Oct 31: 100.00% uptime, 32 checks
Nov 1: 100.00% uptime, 32 checks
Nov 2: 100.00% uptime, 32 checks
Nov 3: 100.00% uptime, 32 checks
Nov 4: 100.00% uptime, 32 checks
Nov 5: 100.00% uptime, 32 checks
Oct 7 Today
No downtime Partial Downtime Not measurable No data

Measured by FlareWarden's own checks of buffer.com from multiple regions every 6 hours. Buffer's status page sets the verdict above when it reports trouble, but never these figures. Percentages count only checks that returned an availability answer — 90 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

What Buffer does

Buffer schedules posts to social networks from a single queue, aimed at small teams and individual creators rather than large enterprises. Users load a week of content at once and stop thinking about it, so an outage tends to be discovered days later through a gap in a posting schedule nobody was watching.

What an outage looks like

Scheduled posts do not publish at their set time, and the queue shows them as pending or failed afterwards. Connected channels appear disconnected and ask to be reauthorised. The dashboard fails to load or shows an empty queue, which is alarming but usually a display problem. Analytics stop updating and the publishing API returns errors.

What to do about it

Check status.buffer.com, which groups components into Core Buffer, Social Networks and the Developer Platform, so a failure affecting one network does not mean the whole queue is stuck. Verify on the social network itself whether a post published, rather than trusting the queue, and avoid rescheduling anything that may already have gone out.

Is it down for everyone, or just you?

If this page says Buffer is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 17 cities across three regions to find out where it breaks.

Test it yourself

Related services

Buffer outage FAQ

Did my scheduled post publish during the outage?
Check the social network directly rather than Buffer's queue, because the two can disagree. A post may publish successfully while the queue still shows it pending, and the reverse also happens. Missed posts are not always retried automatically, so anything tied to a campaign date is worth confirming at the source.
Is Buffer down or has a channel disconnected?
Social networks expire access tokens periodically, and a disconnected channel is far more common than a Buffer incident. It shows as one network failing while others publish normally, with a prompt to reconnect. Check status.buffer.com, then reconnect the affected channel rather than waiting for a status page that will stay green.
Do failed posts retry automatically?
Not dependably. A post that failed at its scheduled time may sit in the queue marked as failed rather than being re-attempted, and the timing that made it worth scheduling has usually passed anyway. Review the queue after any incident and decide which items are still worth publishing rather than assuming they went out late.
Why is my queue empty when I had posts scheduled?
An empty dashboard during an incident is usually a loading failure rather than deleted content. The queue is stored server-side and reappears when the service recovers. Avoid rebuilding the schedule from scratch while the dashboard is unreliable, since the original posts return and you end up publishing everything twice.
Does a Buffer outage affect posts already published?
No. Once a post reaches a social network it belongs to that network, and Buffer has no further role in serving it. Anything already live stays live and visible to your audience regardless of Buffer's state. What an incident affects is scheduling, publishing and the analytics gathered afterwards.

How we measure this

  • We request Buffer's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them. When you open this page and our last check is more than 30 minutes old, we check again on the spot; those checks update the verdict, never the availability figures.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. Our checks only change their verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Buffer publishes an official status feed we read it too, and the verdict is the worse of what it reports and what our checks see: a major outage of Buffer itself is Down, trouble with one part of it is Degraded, problems at a few of a provider's many locations change nothing, and a security notice that marks nothing down is shown but changes nothing either. We check the feed every 3 minutes and read it again within minutes of any change to its incidents or components; a reading counts for 45 minutes after the last check that found nothing changed. The availability figures above are our measurement alone.

Get alerted when Buffer goes down

We check Buffer every 6 hours, and again when you open this page if that was more than 30 minutes ago. Your own monitors run as often as every 30 seconds, from up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required