Unexplained Twitter failure during WWDC 2009

If you follow @macjournals on Twitter (thank you), you probably noticed that our live coverage of the WWDC 2009 keynote came to an abrupt end at 11:11 AM PDT (2009.06.08 1611 GMT) with this tweet:

You undoubtedly know that the keynote continued beyond that point. You can view the event as a live stream, or download it to your computer (or iPod or Apple TV) by subscribing to the Apple Keynotes podcast in iTunes, but that doesn’t explain why our updates stopped after 63 messages.

At least we weren’t alone: virtually the same thing happened to the Twitter coverage from @maclife. A reader told us that the same happened to @macrumors, but their coverage seemed to have come back and filled in the gaps, even though we’re told the live updates stopped during the event.

One significant difference: @macrumors only posted about 20 tweets during the keynote. We, and @maclife, posted significantly more (63 for us in the first hour, as noted). We mostly use @macjournals for live event coverage, and 63 messages shouldn’t be any problem at all, especially given Twitter’s documented limits:

What are the limits?

We’re starting with a few limits based on various parameters, and we’ll be adding more as time goes on. We reveal some limits only when you reach them, and tell you about others in advance. Twitter currently applies limits to any person who reaches:

  • 1,000 total updates per day, on any and all devices (web, mobile web, phone, API, etc. )
  • 1,000 total direct messages per day, on any and all devices
  • 100 API requests per hour

We’ve also placed limits on the number of people you can follow. The number is different for everyone, and is based on a ratio that changes as the account changes. If you hit a follow limit, you must balance your follower/following ratio in order to follow more people- basically, you can’t follow 50,000 people if only 23 people follow you. Based on current behavior in the Twitter community, we’ve concluded that this is both fair and reasonable.

Given this knowledge, you can understand that when updates stopped flowing, we at GCSF World Headquarters assumed that network access at the venue had broken down, or John’s device had drained its battery, or something similar. So we tried posting a couple of updates from here linking to other coverage.

Those didn’t show up either. We had a mystery.

In an attempt to get back to the basics of the problem, we posted an update from Twitter’s Web page, using no client other than the service’s own Web interface. (This would rule out any chance of it being a Twitter API problem or limit.) After doing that, Twitter’s Web page displayed something strongly resembling a sheet sliding out from the top of the page that said something very similar to this:

Wow, you’ve tweeted a lot today! You’ve exceeded your capacity for now; try again later.

(I apologize for not having exact wording or a screen shot; I was so surprised that it simply didn’t occur to me)

We have been unable to find any Twitter documentation explaining how 63 messages in 67 minutes triggers any documented limit. What’s worse, though, is that Twitter did not return errors to Twitter clients while refusing these messages. Until trying the Web interface, we had no idea Twitter was receiving our messages, only to discard them.

We tried a couple of different Twitter programs during this “tweeted too much” period, and everything we tried accepted our messages without complaint. They just didn’t show up. They never showed up, not even days later. And we were never told. Had I not tried to use the Web interface, I would not have seen the mysterious “you’ve tweeted too much” sheet, and I still wouldn’t know what happened.

We have yet to find any explanation for what happened, or any explanation of what is obviously a Twitter limit policy. You can imagine a Twitter program showing a message about an application-imposed limit, but the Twitter Web site itself only displays messages sent by Twitter’s servers.

This raises serious questions for us about using Twitter for live event coverage. We chose Twitter for live events because of its simplicity. We send simple, small updates to the service, and it makes them available to you in whatever way you choose: text messages, via a Twitter client (at an update rate you choose), via RSS feed, or just via the Web. “Liveblogging” is more complicated because in addition to adding content at a furious pace, we also have to keep the HTML updated and published, and one mismatched tag can make the page undisplayable. Twitter takes care of those details and many more for us, and you don’t even have to sign up to see the updates on the Web or via RSS.

That falls apart when there are hidden, undocumented limits on what we can send, and it dissolves into protoplasmic goo when messages are accepted without error and then discarded. That’s what happened on Monday: John spent the next hour or so after the last message sending live coverage of the event to Twitter, which then threw his messages away without telling anyone. Those writings are now lost forever. That’s never going to be acceptable.

We’re not even sure how to ask Twitter what happened, and right now, it seems like they’re busy dealing with the Twitpocalypse anyway. We’re not sure what we’ll do for live event coverage going forward, but we definitely need to find some assurances from Twitter about what already happened on 2009.06.08, and instructions on how to avoid it in the future. If Twitter doesn’t explain, or the limits are too onerous for live event coverage, we’ll have to seek out a different service.

If it comes to that, we’ll let everyone know both here and on the @macjournals Twitter feed. We apologize for the inconvenience, but to the very best of our knowledge, it was not our fault.