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



StatusCake maintenance windows have recently been re-released with improved features.
Having listened to your feedback we decided that it was time to completely revamp the system and offer something new and more functional. You will now be able to set time periods where you will not be notified of your site downtime; an excellent solution for telling our systems to automatically ignore things like late night scheduled server restarts. You can create as many maintenance windows as you like, and apply them within uptime tests.
In the past you could find this section within each individual test, but now we have given it it’s own section, just click “Maintenance” in the StatusCake Dashboard to view the page. Here you can set up windows by entering the desired start time and duration, the time zone used will match the one selected in the user details section of the account.
You can preview the window that you have set up before you create it to ensure that the future dates are all correct, once it is submitted you can simply add it to the Maintenance field in by editing a test and going to the test settings section. All of the windows that you set up will be viewable on the maintenance page. Maintenance windows are available on all StatusCake paid plans.
Share this
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
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
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.
4 min read In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already
Find out everything you need to know in our new uptime monitoring whitepaper 2021