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
It’s now been two days since we sent out our customer survey and while yesterday’s focus was on server reliability and speed, today has very much been about the way in which we deliver alerts, and more specifically our email notifications to you. At StatusCake we sends hundreds of thousands of email alerts a month – letting you know when you website has gone down, and then when it has come back up.
Whilst the vast majority of our email alerts make their way through the system without any issues we have seen some getting caught by spam filters, others arriving long after we’ve sent them. These issues are not unique to StatusCake, all companies that send the amount of emails we do can face such challenges. But given the importance of getting notified to website downtime, we want to eradicate even the small of issues.
Up until now, email alerts have been out from our own internal IP. We used a dedicated server for the managing and sending of our monitor alerts. But whilst this has been working great in most cases – and in particular enables us to offer unlimited email alerts to all our customers both free and paid accounts – there have been some isolated issues. And we want not only to get rid of those, but also make our service more reliable and better than ever.
SMTP service
So today we decided to move over to a premium email SMTP service – we will in effect be paying for every email sent and with this we can ensure better reliability and speed of service. But rest assured. We will continue to offer unlimited email alerts to all our customers. When it comes to ensuring a better service for our users – the cost to us doesn’t come into the equation – it’s something we want and need to do to improve our website monitoring service.
From today all email alerts will now be recorded through the communication chain to the remote inbox. And when an email addresses that you’ve set-up in a contact group bounces or get rejected we will sent an alert to the account holder’s email (where this is a different email address) and will notify you of the problem with your email address within the control panel. This way you can always be sure that the email address you have set-up for notifications is working – making sure you can be 100% that notifications are going to reach you.
We’ll be running our new SMTP service over the coming few days, with all users being migrated to the premium SMTP service by Tuesday.
SMS text-messages, Boxcar, Pushover and Zapier all work well and we have had no reports of delays on these services (except when one of the services in question has had a fault outside of our control).
As always a huge thank you to people who completed the customer survey – we really do listen to your responses and learn from them.
James Barnes
Share this
More from StatusCake
Buy vs Build in the Age of AI (Part 2)
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
James Barnes
March 11, 2026
Buy vs Build in the Age of AI (Part 1)
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
James Barnes
March 4, 2026
Alerting Is a Socio-Technical System
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
James Barnes
February 25, 2026
Designing Alerts for Action
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
James Barnes
February 18, 2026
A Notification List Is Not a Team
3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years
James Barnes
February 11, 2026
Alert Noise Isn’t an Accident — It’s a Design Decision
3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.
James Barnes
February 4, 2026