tl;dr – Buffer experienced interrupted service due to the AWS outage on Tuesday. All is back to normal now, and all posts are going out as expected.

We know how important a reliable social media experience is for you, and we recognize how interruptions to Buffer can have a significant impact. We’re incredibly sorry for the disruption we caused you today.

Here is precisely what happened and how it may have affected you.

What happened

For several hours on Tuesday, one of Buffer’s main hosting providers at Amazon Web Services (AWS) experienced an outage. The AWS outage affected a number of major websites and tech tools, including Buffer. You can read more about the outage here.

Specifically, the downtime with AWS interrupted Buffer’s ability to send scheduled posts, both text posts and posts with media attachments like photos or videos.

We have since returned to full service. AWS is back up, and all scheduled posts are being sent as expected.

How the interruptions may have affected you

During the outage, we experienced interruptions with our ability to send scheduled posts. Particularly, this had a big impact on scheduled posts with media attachments of photos or video.

When these posts fail, you may notice this in a couple ways:

  1. We send an email to the account owner of the social profile, letting you know that the post failed to go out.
  2. We mark the failed post in the Buffer dashboard with a red tag to indicate that it wasn’t published.

If you’ve seen either of these messages regarding your social media updates, we’re incredibly sorry for the trouble and for the extra work we’ve caused you.

We’d love to do all we can to get things back on track for you.

You can resend any failed updates directly from the Buffer dashboard.

To do so, go to your social profile and to the posts that failed. You can retry these failed posts in a couple of ways:

  1. Retry now, which will publish the post right away.
  2. Retry in Buffer, which will send the post to the end of your queue to publish at the next available time slot

Retry in Buffer failed post

Any questions? We’re here to help

We’d love to do everything we can to get things working perfectly for you and to answer any questions or concerns at all. If you’re still seeing trouble with your posts, you can reach us at hello@buffer.com, on Twitter @buffer, or in the comments of this post.

Many thanks again for your support of Buffer and your grace with us in situations like this! Have a wonderful Wednesday. ☺️

Free up your day with our Social Media Tools

Buffer can save you up to an hour a day and grow your traffic too.

Learn More
Written by Åsa Nyström

Director of Customer Success @buffer | Happiest when I’m practicing yoga or traveling the world ♡ | Sydney ✈️ NYC✈️ London

  • Peter K

    I’m thinking there should be a little more than a “sorry” when a time-sensitive service such as Buffer stops working. Maybe a free month or something?

    I understand that Buffer didn’t fail, it was AWS. But Buffer did fail, and it failed because it relied on AWS. Customers don’t care if an Apple product fails because the issue was with Foxconn components, they just care that their Apple product failed–and Apple rightly is the one who must remedy the situation with their customers. Same with Buffer.

    It is easy to start a cloud biz by using services like AWS, but along with that comes the liability of relying on these third-party services. In this case, your reliance on third parties broke your service. So you shouldn’t pass the buck with your customers, you should take responsibility for your service outage and make amends.

    This isn’t just a Buffer issue, it is a SaaS issue in general. Buffer should do the right thing to its customers and also take a leadership role regarding this lack of responsibility in the industry (and also seek compensation from Amazon if you’re not already doing that, too).

    • Juan Sebastián Suárez Valencia

      Yeah, you lost a ton of money because you had a delay on your facebook post…
      This is my gift for you on behalf of Buffer : https://www.youtube.com/watch?v=APDS_-cICyA
      Now stop crying and go back to work.

      • Peter K

        There actually are realistic scenarios where Buffer outages can cost people money. A couple that come to mind right away:

        1. Event-based business posting. If you’re posting about an event, say the Super Bowl or a flash sale, scheduled posts that don’t go out can lead to significant lost money.

        2. Time as money. If you’re hitting your head against a wall for 20-40 minutes trying to schedule a bunch of posts and can’t figure out why (is it my connection? Is it the image? Is it…?), that costs real money depending on your hourly. Especially if you have to bump something else later to come back to the scheduled posting job.

        A delayed FB or Twitter post about your cat probably isn’t going to matter much, but the value of a service disruption for businesses that rely on Buffer can cost real money.

        For free accounts, for beta product, this is not an issue. But Buffer sells itself to businesses and makes money from its service. If it advertises “this might not work,” I’m not sure businesses would choose it.

        This isn’t an attack on Buffer, per se; we know AWS had the outage, and most of us appreciate the good folks at Buffer. This is a question about shifting liability in the SaaS age and what sort of response a good business should have when there are failures in the stack that the business uses to make its money and deliver its service.

        If I build my business partially on Buffer and it fails, my business fails and my customers look to me. If Buffer builds on AWS and it fails, we look to Buffer.

        Consumer don’t and can’t assume liability for every contractor and decision (such as redundancy) that a business makes behind the scenes–this liability falls to the business that puts the service together and earns money from these efforts.

        This is generally understood in the real world and codified in law, but I’m not sure liability has been thought out in the race to monetize the new SaaS model. There’s a lot of money being made in the tech industry, but part of that money is coming from shortcuts in redundancy and passing along liability to consumers when it should rest with the business.

        Buffer consumers paid for the outage because the liability of the Buffer stack was shifted to them. Since Buffer is a thoughtful business that does seem to care, I thought this move was worth questioning. Buffer has the opportunity to do the right thing and draw attention to a huge issue that is not being talked about enough.

        I’m not writing to attack Buffer. I’m writing because I respect Buffer’s responsible business practices and its commitment to its customers.

      • Peter K

        There actually are realistic scenarios where Buffer outages can cost people money. A couple that come to mind right away:

        1. Event-based business posting. If you’re posting about an event, say the Super Bowl or a flash sale, scheduled posts that don’t go out can lead to significant lost money.

        2. Time as money. If you’re hitting your head against a wall for 20-40 minutes trying to schedule a bunch of posts and can’t figure out why (is it my connection? Is it the image? Is it…?), that costs real money depending on your hourly. Especially if you have to bump something else later to come back to the scheduled posting job.

        A delayed FB or Twitter post about your cat probably isn’t going to matter much, but the value of a service disruption for businesses that rely on Buffer can cost real money.

        For free accounts, for beta product, this is not an issue. But Buffer sells itself to businesses and makes money from its service. If it advertises “this might not work,” I’m not sure businesses would choose it.

        This isn’t an attack on Buffer, per se; we know AWS had the outage, and most of us appreciate the good folks at Buffer. This is a question about shifting liability in the SaaS age and what sort of response a good business should have when there are failures in the stack that the business uses to make its money and deliver its service.

        If I build my business partially on Buffer and it fails, my business fails and my customers look to me. If Buffer builds on AWS and it fails, we look to Buffer.

        Consumer don’t and can’t assume liability for every contractor and decision (such as redundancy) that a business makes behind the scenes–this liability falls to the business that puts the service together and earns money from these efforts.

        This is generally understood in the real world and codified in law, but I’m not sure liability has been thought out in the race to monetize the new SaaS model. There’s a lot of money being made in the tech industry, but part of that money is coming from shortcuts in redundancy and passing along liability to consumers when it should rest with the business.

        Buffer consumers paid for the outage because the liability of the Buffer stack was shifted to them. Since Buffer is a thoughtful business that does seem to care, I thought this move was worth questioning. Buffer has the opportunity to do the right thing and draw attention to a huge issue that is not being talked about enough.

        I’m not writing to attack Buffer. I’m writing because I respect Buffer’s responsible business practices and its commitment to its customers.

        • Even so, when we choose to use certain tools we understand that those businesses providing the tools are not liable for any loss of any kind, it’s in all ToS. So for those on the awesome plan we’re talking about $0.0139 cost per hour or the business plan $0.139 cost per hour.

          It’s not that SaaS are just passing the buck, and especially not when handled the way Buffer handled it. It’s the cost of doing business in some models. Customers enter that agreement understanding this. Therefore it’s an informed choice that they’re making. If they’re not informed it’s their own fault, read the ToS – ignorance is no excuse.

        • Juan Sebastián Suárez Valencia

          If you spend 20 minutes figuring out why the post was not sent, you deserve to pay 20€ to the society for your stupidity and not the other way around. And then if you cannot take your little hands and do the post yourself instead of spending 20 minutes writing your explanation, you need to pay 20€ more. And now you need to pay ME 30€ because I spent some time replying to your useless post.

    • Very good point, Peter! It’s a tricky line to balance, right? We want to completely own the responsibility for Buffer posts failing to go out … yet in the course of explaining why, we end up sharing about AWS outages. We hope we got the message correct here: It’s on us, we’re the ones who chose to rely on AWS, and we’re the ones who’ve built trust from customers that posts will go out when scheduled, no matter what.

      Thanks for offering this food for thought — and in such a kind and gentle way!

      • Peter K

        No worries, Kevan. Not sure if you saw my longer followup comment (it initially was flagged as spam), but I completely understand that it is a tricky balance. I suspect there’s a liability transfer issue that the SaaS industry doesn’t fully take seriously yet because it can be hard in cases like this and constrain the industry’s profit growth. Responsible firms like Buffer can help show the way forward, however, which is why I took the time to jump into this discussion.

        Keep up the good work!

        • The only flaw I see in this reasoning is that while Buffer choose to use a third party service, so have all Buffer customers. We could be using the built in FB schedulers. But instead we choose Buffer (obviously because they’re awesome). The downtime was not the fault of Buffer and it was only a couple of hours. I don’t agree that there should be any financial compensation. Just my two cents worth 😉

  • Thank you for being so transparent about what happened and for giving instructions on what we would notice and how to fix it. Good job on jumping right in to mitigate the outcome.

    • Peter K

      Amen!

    • So glad this post hit the mark for you, Jane! Service interruptions are always a tough one, most of all for the customers it affects. Happy to hear we may have helped folks get on track here.

  • Instead of hiding anything, Buffer is always one step ahead when it comes to taking responsibilities for their faults. Thanks for the proper solution.

    • Hi Mit! Thanks for the comment. We truly appreciate your understanding and support on this one. :)

  • When it comes to Customer Care, Buffer is the best. Great demo of living-breathing social. True what they say, social is not something you do, it’s who you are! Thanks for keeping it real in an age where genuine openness, authenticity, transparency are rare. Kudos!

    • Thanks so much, Amar. Your support means a ton to us!

      • You got it, Kevan. Much appreciated. Cheers 👍

  • Glad to see u back..

  • Thank you Buffer Team for quick reaction. I’m wondering – how can you as a service and we as users prevent it from happening in the future? Do you plan to have some separate backup outside AWS?

  • John

    The best customer service! I love how transparent they are, no BS. I love it when companies are honest and direct rather than using political statements!! #GoBuffer :)

  • Ricardo Ramos

    Off topic.

    Food for thought.

    A question about websites.

    In my opinion, websites are fundamental for a company. It’s always a place controlled by the owner and a point of contact to the client. However, with users being able to encounter your brand and services through a variety of channels, makes me think if a website is a vital part of a digital strategy.

    Users have been changing their behaviour towards mobile apps and social media, in prejudice of websites. This behaviour is certainly decreasing the number of clicks/visits on the web page, making them less necessary.

    To illustrate my point of view, imagine this scenario:
    On my Facebook news feed I find an article review about a restaurant, and after reading the review, I feel compelled to visit the place. To get to know others opinion, I decide to make a search on Tripadvisor or Foursquare platforms.

    After reading positive reviews from others, I decide to ask my wife through WhatsApp if she wants to join me.

    To know where the restaurant is, I search for it on Google. The search result provides important information on the right side like the review from others and also includes a button to directly call the place, which I use to make the reservation. Google Maps provides the information of the exact location and I can use Uber to go to the restaurant and Waze to check the traffic conditions.

    This scenario illustrates the possibility of making everything by only using Mobile Applications and Social Media platforms, without the need of visiting the restaurant’s website.

    Adding this, Statista states that Facebook is already the main source of traffic for news publisher’s websites ( https://www.statista.com/chart/5143/referral-sources-for-online-publishers/ ).

    Websites are only providing content to Social Media platforms, and users only visit the mobile web page of a company if they don’t have the app.

    From an entrepreneur point of view, is it worth to invest in a website? Should he include a website in its business strategy? Does a website continue to be a powerful tool of marketing?

    Can you imagine a different future for websites? Will they only exist to provide content to Social Media and mobile apps or will they evolve due to the development of 3D, augmented reality, virtual reality or other?

    I would love to read your oppinion about this subject.

    Thanks!
    Cheers.

  • Roshan Singh

    Thank you for sharing your experience! – How to Open & Convert .aspx file to .pdf file

  • varsha singh