Making a Simple Status Bar for Your App

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.

Digging in

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

The attractor

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.

Instrumental Free Trial

Understanding what's happening with your software is only possible if you monitor it at the code layer. From agents to our metric-based pricing, we’re focused on making it easy to measure your code in real-time. Try Instrumental free for 30 days.