A "status" page for a high-traffic web service such as Twitter is meant to provide users with service interruption news when the main site is offline or malfunctioning in some way. What it should not do, is be offline itself.
Twitter uses a Tumblr.com blog for reporting service interruptions, and I cannot fathom why. Tumblr is a good life-blogging service, but they have had a lot of service problems over the years. I would not select Tumblr for a mission-critical aspect of my business, were I to have a business that served millions of people.
Inevitably, when Twitter has a sustained period of downtime, their status page goes down as well. This defeats the purpose of having a status page. A flood of users are directed at Tumblr when these outages occur, and Tumblr doesn't seem to be able to handle this kind of load. It seems unfair of Twitter to abuse Tumblr in this way. Tumblr is a free service— I don't know if Twitter pays them a dime for barraging them this way periodically, but I bet they don't enjoy it, one bit.
Plain and simple, Twitter should manage their own status site. They have the resources to do it. Such a site should be static in nature and should be backed by enough redundancy to keep it operating even if every Twitter user were accessing it (the resources would be a small fraction of what is necessary to operate the full Twitter service). It shouldn't be Tumblr's responsibility to report service interruptions for Twitter.
Additionally, their downtime service should include an API as well. This way, if an application is getting an error, it can ping the downtime API to let the user know what's going on. This is particularly important when Twitter has decided to bring their services back up incrementally, making their web site work again, but leaving their API disabled until later. The downtime API can be fully static as well, returning JSON data instead of HTML, that's all. It need not require any dynamic Ruby/Scala/whatever backend to do that job.