External monitoring of Azure web apps with Statuscake

The problem with monitoring from within the platform your app lives in, is that you’re unaware of any connectivity problems that exists outside of your environment. True, you’re not wanting to be monitor Internet weather either but in reality having both monitoring systems is a must.

Statuscake, is an endpoint monitoring service that offers a bunch of features around web endpoint monitoring – but i’ll just be looking at the most basic http check which will look for a 200 response.
*There are many other services available that perform this function – including Pingdom which I’ve used for years (and actually monitors this blog).*
When I first found Statuscake, years ago – it offered more monitoring servers in the UK than any other provider so provided the USP. What I liked about it was the API and the service it provides as part of its free tier.

statuscake monitoring

I’ve written several automation scripts against it’s API and have one blog post here.

Now that we’re happy with Endpoint monitoring through Statuscake, here’s the powershell functions I’ve written to perform a bunch of standard tasks.

So how can we get some monitoring action happening from Azure? Let’s stick to powershell and start using the Azure cmdlets to query all the Web App endpoints. Once we have the list of Azure addresses, we can then query Statuscake to see which one’s do not yet have a monitor set up – then add it. In this way we can host the powershell in Azure Automation to run on a scheduled basis.

What this will give you for free, is a record of availability and performance metrics. It can be extended to alert you upon detected downtime. In short, you’ve got nothing to lose by monitoring all your Azure App Services automatically. In fact a side benefit of the monitoring will be that in the event your Web Application app pools go to sleep, monitoring will keep them alive.

Powershell scripts available on GitHub.

DR environment for Azure Api Management | backup and restore

Azure API Management allows the entire service configuration to be backed up to a storage account.
Either on an ad-hoc basis or on a predefined schedule using Azure Automation, you can back up and restore the configuration to another API Management instance (in another region for DR).

I’ve found that it takes about 15 minutes to restore the configuration, during which you cannot make any other changes to the APIM service, or use the Publisher/Developer portal. This includes any changes that you try to apply using Powershell/Xplat-cli/API, you will receive an error that you cannot make changes whilst the configuration is being applied.

It should be noted that after restoration, the usage statistics are not carried across, the APIM instances usage statistics will remain. The backup/restore is really intended for syncing Production with other non Production environments (DR, Pre-prod, etc). Not to be used to apply release changes to your production environment.

Official MSDN Docs;
Backup-AzureRmApiManagement : https://msdn.microsoft.com/en-us/library/mt619281.aspx
Restore-AzureRmApiManagement : https://msdn.microsoft.com/en-us/library/mt619278.aspx

Powershell script

Estimating your annual Azure bill

Following on from my last post when i was tinkering with the Azure EA Billing API…

If you have an Azure Enterprise Agreement, you might want to get a regular idea of where you usage (and money) is heading.

I got the idea from MyFitnessPal, which is a popular nutrition app.  At the end of every day, when you’ve logged your food and told it that you’re finished eating for the day it tells you that; “If every day was like today, then in 5 weeks you’d weigh 160lb’s” (Or something similar).

With utility billing, your usage could fluctuate wildly from day to day so it’s probably best not to take the single estimate without context from other metrics and information… But it’s fun to see what the bill would end up being.

Rather than just providing a straight powershell script, i’ve created a workflow that runs in the Azure Automation platform and submitted it to the public runbook gallery.

“Uses the Microsoft Azure Enterprise Agreement API to estimate your annual Microsoft Azure bill based on the last days usage.

The default Azure EA account is the sample account id and accesskey just so you can see it working before plugging your own details in. You should use the Microsoft Azure Enterprise portal to request your own accesskey.

I recommend adding the script to a daily schedule.

This script requires a credential asset for the your SMTP server in order to send the email.”

Here’s the (v1.0) version of the powershell script;

Netsuite Suitetalk API – Getting started with c#

Not finding a great number of c# examples using the Netsuite Suitetalk  API i thought i’d post a basic example of using the web service.

This simply just authenticates, gets a list of all the users and outputs their names and email addresses to the console.


Netsuite API Error – This document you requested has moved temporarily

Immediately after downloading the latest WSDL, I started getting an error back from the login method.  “This document you requested has moved temporarily”,   the url is the one from the Netsuite Platform Guide : https://webservices.netsuite.com/wsdl/v2014_2_0/netsuite.wsdl

As per the error, the default  URL was indeed wrong.  However the URL it suggests in the error message is

Which doesn’t work either.

The actual URL that you’ll want to use is

For more about Netsuites Suitetalk API see http://gbyers.byers.me/?p=401