Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021



Whether you’re a novice start-up founder or a battle-hardened veteran SaaS CEO determining key metrics, those all-important KPIs to measure the success of your business, and yourself, is never easy.
Setting metrics that flatter your “achievements” serves no one, not even you. If you’ve got investors they’ll not be impressed by vanity metrics and will almost certainly tell you to come back with something altogether more meaningful to measure the health of your start-up. And if that happens it’s really not the best way of building a relationship and your reputation with the VC that you’ve fought so hard to woo and win over.
Even the SaaS fool or jester would accept these days that simply gauging success, at least in the medium to longer-term (certainly if trying to build a sustainable business), is not just about numbers of customers.
This of course is not entirely true. It is to do with customers, in part, but more how they interact with your business. So what “interactions” should we be measuring?
If cash-flow is king then how much cash your customers pump into your SaaS eco-system is paramount (and of course a key metric), but below this, and at a more granular level, what key indicators can help us predict just how much cash, revenue – that all important MRR and ARR – is each customer putting in, and predicted to put in for the lifetime that they’re with you. Until they churn and leave you for another.
A mistake many SaaS businesses seem to make is to look at in-app or on-site activity as being an indicator that the customer is happy and therefore unlikely to churn. Right and kerching? Wrong!
Assumption is the mother of all… you know the saying. Don’t just blindly assume that because a customer is actively logging in, maybe once a week, or once a fortnight that they’re happy and unlikely to churn. This same hypothesis equally leads you to the exact and opposite conclusion that if a customer isn’t logging in they’re miserable and about to churn. Time to panic? Again no, that’s wrong.
Let’s use StatusCake as example. We have for instance many thousands of very happy customers who rarely login to their accounts. Why? A number of reasons. Firstly if their website is up and stable they may feel they have no reason to login. They simply rely on our downtime alerts to let them know when their site goes down and they simply go fix it. They also have the option to select daily or weekly uptime reports, so again, with all the information delivered to their in-box when they want it, and how they want it again there really isn’t a real burning reason for them to login.
By understanding that the “active” login metric is to some extent meaningless it helps us move away from daily or monthly active customers as being a “good thing” and “inactive” customers, those who may not login for week-after-week as a “bad thing”. If we didn’t understand the context behind “active customers” we’d actually be panicking and chasing after our happy “inactive” customers, and be sitting back happily basking in the glory of our “active” customers. Thank goodness we don’t. Neither should you.
Whether or not a customer is happy is determined, quite simply, by the value they get out of your product. Value not just in terms of pricing (in fact this may be quite a low priority for them – see our recent blog post on Why Customer Choose to Fly With You), but in terms of the intangible value – ease of using the product, meeting the customer’s own goals – perhaps being required to be able to use your tool to deliver reports to an internal client or their own customer – how easy do you make their life?
So don’t blindly follow logins. I myself have, perhaps far longer than the average customer, logged in repeatedly to products I’m giving a spin, trying to work out exactly how to get them to work; hoping with each login that the answer will suddenly reveal itself to me. Perhaps I’m unusual in that respect (most other potential customers will have long walked!), but if you’re using “active” as a sign of success you’re very wrong. In my case it’s simply been a sign of poor user experience and product design, poor on-boarding. In this scenario if you leave me to “happily” carry on logging in you’ll soon see my disappear quicker than you can say “churn”. And you’ll be wondering why that me as that customer that logged in twice a day for a week – that new loyal customer that you’d pinned your hopes on upgrading at some point to a business account – has disappeared in a puff of smoke! What it something we said?
So if “active” and logging in isn’t important then what is?
I would suggest that “active” is the wrong word. Look for engagement. Look for the customer taking steps, or actions that help them towards their end goal. So with StatusCake, if a customer keeps logging into an account without any downtime tests set-up then they’re clearly not getting any value out of the product. They’re neither “active” is any meaningful way, and certainly not engaged. In such a case there’s clearly something stopping them reaching that goal of setting up a downtime test – or whatever that first but key step is with your own SaaS application. You need to find out what that roadblock is and help the customer resolve it. And quickly.
But also think also about the level of paid plan your customer is on. If they’ve signed-up for a subscription with xyz features, how many of those features is the customer actually using? If you find over a period of time they’re paying for your bells-and-whistles plan but only making use of features that are on a lower or even your free tier plan it’s pretty clear that at some point they’ll churn on you. Even if they are logging in regularly!
Quite simply as the title of this blog post suggests it all comes down to one word – “Engagement”. Don’t sit back and ignore customers simply because they login frequently. Dig into your metrics. See what features and tests your customers are setting up. You should be reaching out and talking to them anyway, but if they’re logging in without tests set-up help them. Where they’re on an expensive plan and not making use of the features help them understand what value those features can deliver to them. Help them get them then set-up those features. This is vital and so often got wrong. On-boarding doesn’t start and stop at sign-up. It’s on on-going and fluid process that never stops. So get engaged with your customers now. Even those that are logged in!
James Barnes, Co-Founder StatusCake.com – Uptime Monitoring
Share this
4 min read How AI Is Shifting Software Engineering’s Primary Constraint For most of the history of software engineering, the primary constraint was production. Code was expensive, skilled engineers were scarce, and shipping features required concentrated human effort. Velocity was limited by how fast people could reason, implement, test, and deploy. That constraint shaped everything from team size,
5 min read Autonomous Code, Trust Boundaries, and Why Governance Now Matters More Than Ever In Part 1, we looked at how AI has reduced the cost of building monitoring tools. Then in Part 2, we explored the operational and economic burden of owning them. Now we need to talk about something deeper. Because the real shift isn’t
6 min read The Real Cost of Owning Monitoring Isn’t Code — It’s Everything Else In Part 1, we explored how AI has dramatically reduced the cost of building monitoring tooling. That much is clear. You can scaffold uptime checks quickly, generate alert logic in minutes, and set-up dashboards faster than most teams used to schedule the kickoff
5 min read AI Has Made Building Monitoring Easy. It Hasn’t Made Owning It Any Easier. A few months ago, I spoke to an engineering manager who proudly told me they had rebuilt their monitoring stack over a long weekend. They’d used AI to scaffold synthetic checks. They’d generated alert logic with dynamic thresholds. They’d then wired everything
3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
Find out everything you need to know in our new uptime monitoring whitepaper 2021