I'm looking at it from the customer point of view, but support staff will have a whole different set of requirements from that of the end user - in particular the ability to determine whether a specific customer or site has a problem and often support staff or engineers will have specific tools or software to help with that.
There's no real 'best practice' that encompasses what is really a quite broadly scoped question, at least certainly not in terms of layout, but there are some elements of information you should include.
Consider why visitors are coming to the system status page. Often it's because they have a problem and want to know where the blame might lie - your end or theirs.
So if a provider has multiple products or services which can have independent system issues whilst leaving others unaffected, then it makes sense to provider information on a 'per-service' level so that users can see whether their product is affected.
Or if a provider has geographically dispersed servers which can fail independently, then visitors should be able to determine from the status information whether the problem affects their particular location.
Sometimes a system issue can affect some, but not all customers, in which case a suitable message may by appropriate and would explain why they have a problem but their colleague in the next room may not.
Services can sometimes fail through no fault of the provider, but if the provider knows information that can help users, then the system status page is a good place to put it.
In terms of age of information given, a provider will want to give a generally positive spin on things and may want to balance the positives of showing that systems have been fine for the last week or so, against the negatives of showing that the frequency of system issues are so high that a weeks worth of information always includes one or two issues.
So in order to answer your own question you have to look at how the system may fail (all systems, by service, by location) and assess mean time between failure, and simply provide the information that a customer needs in order to determine whether the problem is likely to be yours or theirs.
Then if possible, back that up with a confidence boosting statistic showing that system issues hardly ever occur, so that next time they have a problem they are reasonably confident that the problem is more likely theirs rather than yours.
It boils down to management of the customer experience - being sensitive to a distressed customer's needs, and providing clarity of information, while also providing an overview of system reliability in order to set their expectations (and hopefully allay worries) for the future.
Above all, the information presented has to be honest - the system status page is not a marketing exercise. Having said that however, a consistently good record can be pointed at as a clear benefit.
