We've made a few changes and given a fresh coat of paint to our Integrations section, here's what's different:
Integrations allow you to send alerts out to a range of external providers, including Slack, Pagerduty and Pushover. This is also the section where you can configure phone-call alerts. If you haven't already - check out the integrations section in your account - and ensure you have a good set of alerting methods configured!
We will soon be launching three Multi-Location Regions for uptime testing, these will be available to all paid customers. Each region will contain 4 locations.
These regions can be utilised in cases where users wish to see confirmations from more than one location per downtime, as such we advise setting 2+ confirmation servers in test settings to ensure that this is taken advantage of.
The details for the new locations can be found below, we would advise whitelisting these new IPs:
USA REGION
| Name | Location | IPv4 | IPv6 |
|---|---|---|---|
| USA9 | Georgia | 66.42.84.197 | 2001:19f0:5400:1d5b:5400:05ff:fec5:f332 |
| USA10 | Florida | 45.77.75.19 | 2001:19f0:9003:0cc3:5400:05ff:fec5:f34f |
| USA11 | New York | 159.89.52.219 | 2604:a880:400:d1:0:3:3b85:9001 |
| USA12 | California | 192.241.213.188 | 2604:a880:1:4a::c0a:b000 |
EUROPE REGION
| Name | Location | IPv4 | IPv6 |
|---|---|---|---|
| NLD5 | Amsterdam | 192.81.222.231 | 2a03:b0c0:0:1051::1bf0:7000 |
| DEU5 | Frankfurt | 161.35.219.158 | 2a03:b0c0:3:f0:0:1:8e81:8000 |
| GBR5 | London | 143.110.160.161 | 2a03:b0c0:1:e0::cecb:2001 |
| FRA5 | Paris | 45.32.148.97 | 2001:19f0:6801:099e:5400:05ff:fec5:f341 |
ASIA REGION
| Name | Location | IPv4 | IPv6 |
|---|---|---|---|
| IND1 | Bangalore | 139.59.95.143 | 2400:6180:100:d0::d038:b001 |
| SGP1 | Singapore | 152.42.203.195 | 2400:6180:0:d2:0:2:6758:f000 |
| AUS1 | Sydney | 139.180.163.76 | 2401:c080:1800:130a:5400:05ff:fec5:f347 |
| JPN1 | Tokyo | 149.28.30.15 | 2401:c080:1000:102b:5400:05ff:fec5:f34d |
We are currently experiencing access issues for users trying to log in to app, this has been identified as an issue with Cloudflare.
Monitoring and API access are unaffected and continue to work correctly. users are covered for outages and alerts.
Many Cloudflare users are affected, and users will see their Cloudflare managed sites generating downtimes through StatusCake, these are valid and will be related to Cloudflare's inability to serve the pages at current.
An outage is developing on the Azure service, Australia and some parts of Asia are currently affected. The issue is worsening and seems to have originated at around 1AM UTC on 03/11 as an intermittent problem, as of 9:30 UTC we are seeing many customers affected.
No update is available yet on Azure status page but third parties have begun to note the outage - https://azure.status.microsoft/en-gb/status
Update 12:30 UTC: The problem has not yet been acknowledged by Azure publicly but some customers are now seeing recovery of their websites.
Azure is currently experiencing a major global outage, impacting customers in multiple regions to varying degrees. Some users are reporting increased latency and degraded performance, while others are seeing complete service unavailability across various services - including Microsoft 365 and other Microsoft services, from Outlook to Minecraft.
There are widespread third-party confirmations and consistent user reports indicating issues with core Azure services. Microsoft has now acknowledged the outage on their status page.
Official Azure status updates can be found here:
🔗 https://azure.status.microsoft/en-gb/status
Impact to StatusCake:
StatusCake services remain fully operational.
We are monitoring the situation closely, but there is no direct impact to our monitoring infrastructure or uptime tests.
Azure is suffering a large global outage, this is affecting Azure customers in all regions to various degrees. With some customers having increased load time, and others seeing their sites & services completely inaccessible.
There's no first party confirmation of this outage as yet, but we are seeing strong confirmation signals from third party reports and our own users we've spoken to who have reached out to Azure.
Issues started around 8AM UTC Thursday 9th October, and persist as of 9:30AM UTC.
Official status updates from Azure can be found here - https://azure.status.microsoft/en-gb/status
Update 10:30 UTC: Azure has now updated their status page, reporting that they have experienced significant capacity loss, about 30% of Azure Front Door instances are affected, affected instances are predominantly across Europe and Africa but other regions may see problems too.
Azure confirm an estimated start time for this outage of 7:40AM UTC, unfortunately issues are still ongoing.
Cogent - one of the worlds largest internet providers, is currently experiencing a serious outage. This will affect routing worldwide, and will likely have a more pronounced effect on websites hosted in the USA, where monitoring is being done from outside that region.
Within the USA the California region seems to be worse affected, we are monitoring the situation and can confirm that none of our systems are affected by this outage. Affected customers might see increased outages as a result of global connectivity issues preventing their sites being accessible.
Customers reports indicate that Cloudflare or a linked provider are having issues in the Australia region, these are manifesting as long load times and 522 errors.
Depending on how long the crawl timeout is set on your StatusCake test, you will see either timeout or 522 errors if monitoring from Australia during this period. It is a valid outage and we'd advise contacting Cloudflare for more information.
UPDATE: 3PM UTC
Unfortunately the issue is still very much present, and may have a flapping/intermittent effect for some users. Seeing tests go up and down.
If monitoring from AUS is not critical, then you can set testing locations within test settings to avoid being alerted on this outage.
Details direct from Microsoft here - https://azure.status.microsoft/en-gb/status
Due to these issues and potentially related routing issues within Canada, and New York we have temporarily disabled these locations.
They will be re-enabled once Microsoft reports this problem resolved.
UPDATE - The issue has been reported as resolved by the affected providers
We’ve made it easier to choose locations when creating a test!
🌍 Select by Continent – You can now select an entire continent instead of picking individual cities. This was a much-requested feature!
✅ Simplified Selection – Each location only needs to be selected once. No more duplicate entries!
🔢 New Limit – You can now select up to 19 locations per test.
Let us know if you have any feedback – our support team is happy to help! 🚀
We're pleased to let you know that our maintenance windows feature available on all paid plans now supports putting PUSH/heartbeat checks into a maintenance state.
This means you can now emit any downtimes and alerts from these tests during periods of expected downtime.
To utilise this new function simply assign a PUSH/heartbeat check to a new or existing maintenance window where relevant.
Please feel free to reach out to our support team with any questions!
We’re glad to announce that you can now pause Push Tests on StatusCake! 🚀
Previously, once a Push Test was created, it continuously expected pushes at the defined interval. Now, with this update, you have the flexibility to pause these tests when needed.
What Does This Change Mean?
No New Test Results: When a Push Test is paused, it will stop receiving and recording new test results.
No Alerts During Pause: If a Push Test is paused, it will not trigger alerts for missing pushes, helping prevent unnecessary downtime notifications.
How to Use This Feature?
1. Navigate to your Push Tests in the StatusCake dashboard.
2. Locate the test you want to pause.
3. Click the Pause button.
4. Your test is now paused and will not receive further updates or send alerts until resumed.
To resume the test, simply click the Resume button, and monitoring will continue as usual.
We have added a new IP address for SSL monitoring, customers should add this to their whitelist if required in any firewalls or security setups:
| Agent Name | IP Address |
|---|---|
| SSL3 | 162.243.140.207 |
This replaces the previous SSL3 IP: 104.236.163.90, which can now be removed from whitelists.
As a reminder, the Monitoring Regions upgrade will go live for paid uptime checks on Tuesday, 14th January 2025.
We encourage all customers to review the Monitoring Regions guide for a detailed explanation of how Monitoring Regions work.
Key Points:
Ensure you whitelist all IPs in your selected Monitoring Region. Smaller regions with just 4 IPs are now available for London, Amsterdam, New York, and Frankfurt.
The updated IP addresses for these smaller regions are available here.
For customers without whitelisting requirements, no action is needed.
Have questions or need assistance? Reach out to our support team anytime.
We’re excited to announce the next phase of our Monitoring Regions rollout.
Deployment for Paid Uptime Checks
Following the successful deployment of Monitoring Regions for free uptime checks last week, we plan to roll out this feature for paid uptime checks as of Tuesday, 14th January 2025.
Monitoring Regions Guide:
We encourage all customers to review the Monitoring Regions guide for a detailed explanation of how Monitoring Regions work.
Key Points:
IP Whitelisting: Both initial tests and confirmation checks will run from any IP within a Monitoring Region. Customers with IP whitelisting requirements must whitelist the entire Monitoring Region.
Regional Size: Most regions consist of only 4 servers. However, larger regions (London, Amsterdam, New York, Frankfurt) have significantly more IPs.
To accommodate customers with whitelisting requirements, we are creating new, smaller Monitoring Regions within these geographies, allowing you to whitelist just 4 IPs rather than a larger pool.
The new IP addresses for these regions can be found here - however they will not be active until Tuesday, 14th January 2025
For Customers Without Whitelisting Requirements: Test settings can remain unchanged.
Future Plans:
Over time, we plan to reduce the size of larger Monitoring Regions by creating new ones or partitioning existing ones, offering greater flexibility for customers.
If you have any questions or need assistance, please don’t hesitate to contact our support team.
Thank you for your continued support!
At StatusCake, we’d like to wish all our customers a happy festive season and all the best for 2025!
As we prepare for the festive break, we’d like to share some important updates:
Code Freeze:
A code freeze will be in place starting Friday, 13th December 2024. This will ensure that there are no unexpected changes for customers over the festive period.
Festive Support Hours:
Between 20th December 2024 and 2nd January 2025, we’ll be operating with a reduced support team.
Response times may be longer than usual during this period, but please rest assured that all tickets will be addressed.
Thank you for your understanding and continued support. We’re looking forward to an exciting 2025 with you!
We’re pleased to announce significant upgrades to our monitoring infrastructure, bringing greater reliability and consistency to your uptime checks. Here are the key changes:
Infrastructure Enhancements – All Monitoring Regions (formerly known as "locations") now maintain a minimum of 4 servers, ensuring robust, reliable monitoring.
Consistent Confirmation Testing – With these upgrades, Confirmation Tests (previously "confirmation servers") will always run from the same Monitoring Region as the initial test, providing accurate validation of downtime events.
Updated Terminology & Best Practices – We’ve introduced new terminology and refined how Monitoring Regions and Confirmation Tests work. For a complete overview, please refer to our updated Monitoring Regions and Confirmation Tests guide, which includes best practices for selecting the most appropriate regions.
Need Help? – If you have questions or need assistance adjusting your setup, our support team is ready to help.
For complete details on these enhancements, please explore the guide and reach out if we can assist with any part of your monitoring configuration.
### Servers
NZ01 and NZ02 will be removed as uptime monitoring locations
We are deprecating our uptime monitoring locations NZ01 and NZ02 due to compatibility and quality issues with current hosting providers in the New Zealand region. This decision is part of a larger commitment to improving the reliability and resilience of our monitoring infrastructure.
We recognize the importance of maintaining diverse geographic coverage for our customers, and we are actively working to enhance our systems and infrastructure to deliver the high standards of reliability that you expect.
We expect this removal to occur on: 10th December 2024
In preparation for this, it will no longer be possible to assign NZ locations to new tests from: 11th November 2024
| Agent Name | IP Address |
|---|---|
| NZ01 | 103.14.141.200 |
| NZ02 | 103.14.141.207 |
Impact
Monitoring checks previously assigned to NZ01 and NZ02 will have those locations removed from their configuration, this location will no longer be available when configuring new tests.
Next Steps
We plan to reintroduce New Zealand-based monitoring locations when possible, pending availability and quality improvements with local hosts.
### Servers
New Monitors
We are excited to reveal that we're expanding the number of monitors available in the Madrid region, offering a more reliable downtime detection service for customers.
| Agent Name | IP Address |
|---|---|
| ES2 | 34.175.21.165 |
| ES3 | 34.175.86.21 |
These new monitors will be available soon, where they may then be assigned to uptime monitoring checks.
Address Changes
Whilst we always endeavour to mitigate the impact for customers, it has been necessary to migrate the current uptime monitors in the Madrid region to another hosting provider. By doing so we're able to deliver a more consistent and reliable service within the Madrid region. However with this comes changes to IP addresses for the 2 monitors in the region. Changes to these addresses will take effect on Tuesday 5th November 2024 at 11:00 UTC.
| Agent Name | Old IP Address | New IP Address |
|---|---|---|
| ES | 194.62.97.161 | 34.175.49.24 |
| ES1 | 194.62.97.232 | 34.175.19.199 |
We are pleased to announce that several new monitoring locations will be added in the coming weeks to enhance our global coverage and improve your monitoring experience. The new IPs for these locations will be available soon:
Belgium
IPv4: BEL3 - 35.187.119.100
IPv4: BEL4 - 34.34.185.236
Brazil
IPv4: BR4 - 35.247.248.27
Johannesburg
IPv4: ZA6 - 13.247.17.60
Dublin
IPv4: DUB4 - 54.170.7.14
IPv4: DUB5 - 52.48.52.95
Hong Kong
IPv4: HK3 - 34.96.139.85
IPv4: HK4 - 34.150.35.14
Mexico
IPv4:
MEX3 - 216.238.84.207
IPv4:
MEX4 - 216.238.77.111
IPv6:
MEX3 - 2001:19f0:b400:205e:5400:05ff:e24:5eb8
IPv6:
MEX4 - 2001:19f0:b400:2036:5400:05ff:e24:5eb9
Italy
IPv4: IT3 - 15.161.88.159, IT4 - 18.102.253.202
New Jersey
IPv4:
UG10 - 140.82.4.219
IPv6: UG10 - 2001:19f0:1000:3df6:5400:05ff:e24:5efa
Seoul
IPv4: SK4 - 34.22.96.192
Singapore
IPv4: SG4 - 35.198.232.244
These IPs will soon be live on our systems and available to pick up tests, we recommend whitelisting them in your firewalls and security settings to ensure the best monitoring coverage. We’ll notify you as soon as the rollout is complete.
Stay tuned for more updates!