Building a Status page for $5 per month

When we first built HR Partner, I wanted to have some sort of status page like most web apps do, to let our customers know about uptime availability and any scheduled maintenance that we had planned.

Our HR Partner status page at: status.hrpartner.io

Looking at most of the commercially available offerings, I found that while excellent, they were quite expensive, when compared to the project management, accounting and bug tracking tools that we already subscribed to.  Being a relatively small, boot strapped startup, I didn't want to add to our already high monthly subscription burden too much at this stage.

Eventually, my search led me to Cachet, which is an open sourced version of a status page app, that seemed to have most of the features that the 'big boys' did.  End of the day, we managed to host Cachet on a virtual server for around $5 a month, and given that the cheapest commercial variant we found was $29 per month, I am happy that we got something working for a budget price that is hard to beat.

Given the buyout of one of the main commercial vendors StatusPage.io by Atlassian today, a lot of people have seen me post about my efforts and have emailed or PMd me to ask how we went about this, so this post will hopefully let you know the steps we took.

Hosting

Our main HR Partner web app is hosted by Amazon AWS, in their us-east-1 region.  Because we wanted some sort of redundancy in case of a major Amazon outage or regional catastrophe, we decided to host our status page on a Digital Ocean Droplet over on the West coast.  Different providers, different infrastructure, different areas.

So the first thing we did was to set up a VPS in Digital Ocean.  I picked the cheapest droplet they had, which was a $5 per month server running Ubuntu 14.04 (64 bit) with 512MB of RAM and 20GB of storage.  Cachet doesn't take much in the way of resources at all, so this was plenty for us.

The Stack

Once the Droplet was up and running, we just opened up a console to the server from within our DO control panel, and installed MySQL on it.  Digital Ocean have a great article on how to do this right here.  We simply followed the instructions step by step.

Next step was to follow the equally great instructions from the Cachet documentation right here to install Cachet on that VPS.

I believe the only tricky thing that we had to do was tweak the permissions within the Cachet folder.  I believe we had to chown the folder and all subfolders to the www-data user and group.

Configuring Cachet

Once we had Cachet installed as per above, we adjusted the .env file to use our preinstalled MySQL instance for the database, and also to use our normal Amazon SES service for the sending of emails.  I believe we had to also change the default queue driver for sending emails.  Here is what our config file looked like:

APP_ENV=production
APP_DEBUG=false
APP_URL=http://status.hrpartner.io
APP_KEY=***secret key here***

DB_DRIVER=mysql
DB_HOST=localhost
DB_DATABASE=cachet
DB_USERNAME=***yourdbusername***
DB_PASSWORD=***yourdbpassword***
DB_PORT=null

CACHE_DRIVER=apc
SESSION_DRIVER=APC
QUEUE_DRIVER=sync
CACHET_EMOJI=false

MAIL_DRIVER=smtp
MAIL_HOST=email-smtp.us-east-1.amazonaws.com
MAIL_PORT=25
MAIL_USERNAME=***yourSESuserIAM***
MAIL_PASSWORD=***yourSESkey***
MAIL_ADDRESS=status@hrpartner.io
MAIL_NAME="HR Partner Status"
MAIL_ENCRYPTION=tls

That was really about it!  (Oh, don't forget to let Amazon SES know about the email address that Cachet will be using to send emails as - in our case status@hrpartner.io.  Otherwise it won't pass the SES spam filtering).

Last thing was to tweak our Amazon Route 53 service to point status.hrpartner.io to our Digital Ocean VPS IP address.  Done!

Now it was all a matter of setting up Cachet with our components and needed to be reported on, and we were away.  All in all, I think the install and configuration took less than an hour to do.

BONUS: Auto update

Because HR Partner is a fairly complex app, with multiple sub apps for the API, reporting engine etc., deployment can take a while to do, and can result in slow performance for up to 15 minutes at a time while the virtual instances are updated and synchronised.

We use Amazon's Elastic Beanstalk command line tools to deploy changes, and at first our procedures meant that before we ran a deployment, we manually logged into our Cachet server to flag the services that would be down, then deployed, waited, and went back to Cachet to flag them 'green' again.

This was quite tedious, and I wondered if there was an automated way.  It turns out there is.  Cachet has a great JSON API, so what we did in our projects was to create a couple of files under the .ebextensions folder in our project folder.  These files contain the scripts that we wanted Elastic Beanstalk to run before and after deployment.  First, we created a file called 01_file.yml for the before script:

files:
"/opt/elasticbeanstalk/hooks/appdeploy/pre/02_cachetupdatestart.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":2}' http://status.hrpartner.io/api/v1/components/2
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":2}' http://status.hrpartner.io/api/v1/components/4
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":2}' http://status.hrpartner.io/api/v1/components/5
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":2}' http://status.hrpartner.io/api/v1/components/6
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":2}' http://status.hrpartner.io/api/v1/components/8

Then we created a 02_file.yml for the after script:

files:
"/opt/elasticbeanstalk/hooks/appdeploy/post/02_cachetupdatefinish.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":1}' http://status.hrpartner.io/api/v1/components/2
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":1}' http://status.hrpartner.io/api/v1/components/4
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":1}' http://status.hrpartner.io/api/v1/components/5
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":1}' http://status.hrpartner.io/api/v1/components/6
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X PUT -d '{"status":1}' http://status.hrpartner.io/api/v1/components/8
curl -H "Content-Type: application/json;" -H "X-Cachet-Token: [secret token]" -X POST -d '{"value":1}' http://status.hrpartner.io/api/v1/metrics/1/points

(Replace the [secret token] above with your unique Cachet API token.)

Now whenever we do an eb deploy command, the relevant status page components are marked 'yellow' for the duration of the deployment, then brought back up to 'green' again when completed.

Cheap As Chips

The only running cost for our status page is the $5 per month for the Digital Ocean hosting.  That is all.  We've been running this configuration for some months now with good results.  When revenue and usage gets to the point where we need to update this, then we may look at some of the commercial offerings, but for now, this setup works well for us.

I hope we have managed to inspire others to try the same.  As always, if you have feedback or suggestion on how we can do this better, I would love to hear from you.

Picking Non Random Colours for the UI

I think we are up to Part 9 of our often interrupted feature posts on the building of our new human resources SaaS app HR Partner.  I've lost count a little bit, but today I wanted to talk about one of the design issues we came across when creating the dashboard.

We love using the little pie charts from chartJS to show the relative breakdowns of male/female employees, or distribution across departments and employment statuses.  The issue was, we didn't know how to best create a colour palette for the pie segments.  You see, our users can have anything from one to many dozens of pie slices, depending on their organisation and operating requirements.

For this reason, we didn't want to create a set number of colours in our palette, mainly in case our customers exceeded this limit.  We also didn't want to generate totally random segment colours each time the chart was generated because I believe that a part of a good UX is consistency, i.e. if a customer is used to seeing light blue for the department 'Finance', then seeing it as a dark red next time can throw them off.

Additionally, one of the big features of HR Partner is that HR consultants may work across completely different company entities on a day to day basis, and it would be nice if the Finance department in one company dashboard was the same colour as the Finance department in a totally separate company.

For that reason, we decided to set the segment colours based on the segment names.  So the name 'Finance' would generate the same colour on ANY company.

Our first efforts at this resulted in some quite garish colour choices which was not pleasing at all, so in the end I decided that we would try and restrict the colours to lighter pastel hues that wouldn't clash too much, but still be fairly easy to discern.

Secondly, I also realised that because our algorithm was only taking the first 6 characters of the name, there could be collisions with similar department or employment statuses (e.g. 'Part time' and 'Part time permanent' would result in the same colour).  I also wanted similar sounding names (like 'Finance' and 'Final') to generate colours that were not too similar to each other, so I decided to do a simple MD5 hash on the name to generate a semi unique hash upon which to generate the colour.  

Here is the Ruby helper method that we use to create the colour for the view.  It simply takes a text seed string, and generates a CSS hexadecimal code for the colour.

def get_pastel_colour(seed)
  # Generate a pleasing pastel colour from a fixed string seed
  colrstr = Digest::MD5.hexdigest(seed)[0..5]
  red = ((colrstr[0..1].to_i(16).to_f / 255) * 127).to_i + 127
  green = ((colrstr[2..3].to_i(16).to_f / 255) * 127).to_i + 127
  blue =((colrstr[4..5].to_i(16).to_f / 255) * 127).to_i + 127
  "#" + "%02X" % red + "%02X" % green + "%02X" % blue
end

I think it ended up quite pleasing to the eye. We ended up using the same code to generate the colour within the calendars too, to get consistency with respect to leave categories.

I'd love to hear from other developers on how to improve on this so the colours can be a little brighter and stand out from each other a little more.

Disclaimer: Not saying we were the first to ever 'invent' this method, but there wasn't a lot that I could find on Google, so I thought I would post here in the hopes that it might help someone else who needed something similar.  The code above is based on something I found on StackOverflow, but I cannot find it again now to post proper attribution.

Who exactly is 'excited' by your latest release?

I've seen it on tons of blogs, tweets and posts... "XYZ is so excited to announce the release of our new feature on our app...".  Heck, I've done the same with my own apps too, so I am just as guilty as anyone else.

But lets face it.  It is usually only the authors, designers and developers that get excited.  And why not? We spent hours/days/weeks building code from scratch, overcoming seemingly unsurmountable technical problems, tweaking, perfecting and polishing.  Of course we will be as excited as new parents are, to release our baby into the wild and get some validation for all that effort.

But consider the user's perspective.  Is 'excited' really the right word for them?  We actually asked a select group of our users over time, and I think the more apt emotion would be 'interested', followed closely by 'apprehensive', or 'doubt'.

You see - as the builder, you have already envisaged what your new features will be used for.  What they can achieve.  How they can be used for the betterment of humankind.  And that is great. You have it all road mapped in your mind.

But most of this takes place behind closed doors, with little or no buy in by the user.  Which is probably as it should be, if you want to focus on maximising your effort and minimising distractions.  After all, no one wants a horse designed by a committee.

What your users eventually see is something new that they have to learn.  Possibly it might be a thing that they could use, but then they wonder if they have the time to learn it and make it fit with their day to day operations.  Will they have to change the way they do things in order to make best use of it?

So perhaps we need to change the way we word new product or new feature announcements.  I certainly intend to do so moving forward.  What would be the best word choice?  Is 'proud' a better way to announce something new?  How do we get 'buy in' from the user to that they feel like they are a part of the journey, rather than just some surprised passer by who has to reel back when developers jump out of dark doorways and say "Boo, I'm so excited about this..."?

I look forward to your thoughts and ideas.

Errors don't have to be boring

This is part 7 in the chronicles of building HR Partner, our latest web app.

A short one today.  I was designing the 404 and 500 error screens for our Ruby framework, and decided to go outside the box a little.

Usually, the 404 error page is a fairly boring affair, telling the user that they have tried to load an invalid page.  I thought to make it more interesting, I would incorporate an ever changing background for the error pages.

I am using a dynamic CSS background for the error pages, which links to unsplash.it to load up a random grayscale image as the background.

This way, every time that a user hits an error page, they will still get the large '404' or '500' error number, but overlaid on a different background each time.  I have no control over what image gets shown, but I find myself just hitting invalid pages every now and then during my development routine - just to see what pretty landscapes show up.

The body style tag looks something like the following:

<body class='black-bg' style='height: 100%; background:url(https://unsplash.it/g/1000/800/?random) no-repeat fixed center center;'>
  ... rest of 404 error info
</body>

So as I said - error message certainly do not have to be boring!