Monitoring a site after launch (part 1)
February 6, 2012 § Leave a comment
A lot of effort goes into launching a project, but often they can be found neglected after launch. We see this more in client projects with a launch date, than with start-ups or any of our internal proprierty work, but the ideas here should apply to all.
It is niave at best, to assume that once launched the project is done – to this end we always encourage clients to budget for work *after* launch. Sometimes this can be a hard sell, because people assume that once something is launched it is done, however argubly this is the most important work to be done. Before launch you are essentially working on educated guesses and experience (or hopefully user testing), but after launch you can see how real users interact with your work and even ask them for feedback.
We have 2 main uses for monitoring after launch:
1, To ensure the site is working as expected
2, To observe usage of the site and be able to react accordingly
Ensuring the site is working as expected
As a dev (or should we say devops), maybe this is the most interesting. I like to write code and I also like to know it works. For that reason we have tests, QA and all of that good stuff. I also like to know when something has been broken, ideally as soon as possible. Mainly so I don’t get woken up in the middle of the night, but also so I can deploy changes with confidence. Monitoring your live site can let you know if something is wrong, if a change you deployed has broken something, or maybe an external service you use is having problems. It can also alert you to the ‘nice’ problem of rapidly growing traffic.
Observing the usage of the site in action
As mentioned in the intro, launching a site is just the beginning. Once its live we’ll (hopefully) have real users using it. This being the case we want to react to how they’re using it and adjust as required. Monitoring the site can tell us many things about usage including how, when and how much. Monitoring can tell us how many people click a particular link or use a particular feature. It can also tell us how long people spend on the site and where they came from.
What should you monitor? Well ideally everything, but more sensibly you want to look at what is most important to your particular app. At a low level you probably want to monitor that the processes required to run you app are operating as expected. Slightly higher up you’ll want to check that pages are rendering and responding as required. Then in the app, well, who knows? Maybe signups are important to you, other people maybe interested in page views, or purchases. At this level it really depends on the app in question.
Part 2 will follow on from this and look at a few tools we use to monitor these different parts.