It’s easy to underestimate the benefits of building lightweight tools. A simple status bar provides substantial insight to devs and admins, is unobtrusive, and can be implemented in an afternoon.
Why should I do this?
By keeping indicators of app health visible during general site usage, errors get caught earlier. Time usually wasted flipping back and forth between the app and sources of key metrics while troubleshooting is reduced. And, you’ll avoid the dreaded, “what the… I keep changing things and nothing is updating… aw crap I’m making changes to development and looking at production”, and similar mixups, thus lowering the frequency of facepalms. Always a good thing.
What to include
Status bars are useful in several scenarios: general site usage, quick check-ins to make sure everything’s ok, and troubleshooting. The items you should include can overlap between these scenarios.
For general site usage and quick check-ins, you’ll want basic activity info as well as any items that will tip you off to emerging issues: think online users, response times, exceptions, and failed jobs. Items that inspire and help maintain momentum are good as well, e.g. recent signups, payments, posts, Tweets, and other user activity.
For troubleshooting, we want info of use when the site is busted, or when a user is experiencing issues. The number of recent errors, failed jobs, slow transactions, server load… you get the picture.
What is, light urple?
Color coding your status bar to match the current environment will nearly eliminate the risk of getting mixed up while flipping between multiple environments. It also minimizes the mental cost of keeping track as you switch back and forth; energy that can be spent elsewhere.
Along for the ride
Posting screenshots of new features or error conditions for others to check out is great. But, what environment were you in? What code revision was deployed? When did you take the screenshot? These bits of context need to be communicated at the time of posting, and can easily be lost over time. By adding them to the status bar, they’ll be there in every screenshot you take.
It’s also not a bad idea to throw in site load and user activity metrics, since they’re particularly helpful when dealing with errors. As more stats are added, the context captured in every snapshot will continually improve.
Status bar summaries should link to more in-depth views of the data. This makes it trivial for anyone using the site to take advantage of the data you’re gathering and the services you’re using to provide visibility into your app. Without this, it’s easy for only the implementors of various services to be aware of the availability of that information and to really know what’s going on. Make it easy for everyone to stay informed.
Examples of linkages:
- Jobs > Resque panel
- Posts > Posts graph / Individual posts
- Tweets > Twitter graph / Individual posts
- Signups > Signup graph / Latest user pages
- Recent Errors > Airbrake
One of the nicest aspects of having a status bar is this: helpful items will be apparent as you experience different scenarios. These helpful bits might otherwise be overlooked, or, worse, might be written down in notes never to be seen or heard from again. But taking a few minutes to implement the status bar is like putting up a whiteboard in the situation room. It will naturally accumulate useful information.