Child Play Color Image Paint Brush Pink Art

Customizing your alerts and reports with StatusCake

At StatusCake a large part of what we do is reacting to current downtime with alerts and logging historical downtime within reports. Today we’d like to take a look at how users can get the most out of customizing these factors.

On our Business level plan all alerts and reports via email can be fully customized to better represent your brand and ensure that the right information needed for your team to address issues quickly and efficiently is always present.

In the image below you can get an idea of the extent to which this is possible, all of our emails the get sent out can be modified as you see fit:

emailtemps

Modifying Alerts

You can modify your alerts for Virus, Uptime, SSL, Domain, Page Speed and Server type notifications in a range of different ways. Each template is managed individually and will apply to all notifications for the set type – you can also set test-specific changes up if there are tests that you’d rather not use the blanket default settings. For changes to all tests you should go to the User Details section for setup, and for changes on an individual test level it’s just a case of editing the test in question and working with the three fields shown below:

mailtemps2

When editing the email’s in the User Details section you’ll be able to change colors, logos and even the base HTML/CSS of the email. We’ve included a range of tags which can be included in the code which will grab data which can make these emails more useful and tailored to your team.

Tag Usage
||TITLE|| Displays Test Name
||SITE|| Displays Website URL
||TYPE|| Displays Test Type (HTTP/PING/DNS etc)
||QUOTE|| TestID and alert number ­ e.g ( 12345 – 1)
||REASON|| Display Cause of Downtime
||TIME|| Display total downtime length for test
||HTTPCODE|| Display the error Status Code
||TESTID|| Display the TestID on it’s own
||CHECKRATE|| Display how often the test is checked.
||HOST|| Display Hosting provider if present
||CONFIRMEDTOTAL|| Show Number of confirmations for downtime
||MESSAGE|| Display custom content set per test
||TAGS|| Include tags attributed to the test
||VALID_FROM|| Display the date from which the SSL certificate is valid (SSL only)
||VALID_UNTIL|| Display the date from which the SSL certificate is no longer valid (SSL only)

So for example, you could populate the subject field of the alert email with these tags, something like “Your Site: ||TITLE|| Is Currently Down 533 ||REASON||”

Modifying Reports

Reports will work slightly differently in that they are showing a historic downtime record for one or more tests, we can fully edit these as well in terms of appearance, title, sender address and tags, and changes will apply both to automatically and manually generated reports.

We use a different set of tags here which can be seen in the table below, bear in mind that these are report specific and will not work for alert type notifications.

Tag Usage
||CU|| Display Total Uptime percentage for tests in report
||WD|| Display Number of Tests with downtime
||WOD|| Display Number of Tests with no downtime
||TABLE|| Display Table of Tests with downtime
||UPTABLE|| Display Table of Tests with no downtime

 

If you’ve got questions on this or would like to know more, feel free to get in touch with our friendly support team who will gladly answer any questions you have!

xdk

Using StatusCake to test login, and a variety of other transactions

With StatusCake you can use a variety of methods to test basic “transactions”, including forms that deal with login, data protection and others.

The Tools

Form and Raw POST data – We can send form or raw POST data along with our normal test requests, in many cases when dealing with HTML forms we can submit this data to the form in order to test the associated function.

Basic Authentication login – For pages where there’s not a HTML form to submit to, and instead access is gained through basic authentication. You can see an example of a Basic Auth dialogue below:

1

Content/String Match – Once we’ve submitted to the form or gained access to the page, it’s important to then verify that the expected page and results are returned. To do this we can use our Content Match feature. This will run a string match for one or multiple strings on the resulting page.

Final URL – You can use the Final URL feature to confirm that the page you’ve reached at the end of the process contains the correct URL, great for catching erroneous errors.

The  Method

First of all you should assess which tools you need to use, and where the testing should be targeted. If you are dealing with a HTML based login form you should submit Form POST data, and your target should be the URL of that form rather than the main page URL.

2

If it’s a basic authentication job then your URL target should be that of the main page, and you should use the basic auth fields on the test on our end to gain access:

3

For other types of HTML form, which could be for a wide range of uses, you just need to grab the field submission names from the source code, these can again be entered in the Form POST field in valid JSON format with your desired values. This way you can use the feature to test pretty much any type of entry form.

4

Validating the Results

Once your form or login dialogue is being actioned, it’s time to set up validation of the process, this can be done in two ways.

String Match – Using the String Match field on the test you can confirm the presence of one or more strings in the source of the resulting page after whichever process has been carried out. You can be alerted optionally if these strings are found/not found.

Final Location – With this you can verify that the final URL in the process is an expected URL, for example if you are expecting http://mysite.com/allgood.php ,  but the URL reached is http://mysite.com/notgreat.php – you will receive an alert for the test.

 

Thanks for reading and just let us know if you’ve got any questions on this via our support channel!

denmark

Some good news for our users in Denmark

Today we’ve launched two new changes that will be beneficial to our users in the country of Denmark, you can read about what’s been added below:

New Copenhagen based monitoring servers

We’ve added several new monitoring servers to cover Denmark and these are based in the city of Copenhagen, all paid users will now be able to select this location when setting up a test – it’s as easy as selecting Europe -> Denmark/Copenhagen in the test’s settings.

We hope that users find the ability to test from this new location useful, and remember if there’s a location you need that we don’t have it’s always worth getting in touch via our live support to let us know!

New payment currency – Danish Krone

We know that pricing in US dollars isn’t great for everyone. First off with exchange rates in such flux nowadays, If the US dollar is strong it makes us more expensive.

Secondly by being tied to another currency it’s likely that you’re paying a slightly different amount each month, and third maybe your debit or credit card company charges you a fee for making USD transactions.

We’ve made life simpler on this front recently by bringing in a wave of new payment currencies – and today we’re glad to announce that we will be introducing Danish Krone to enable our customers in Denmark to pay in their local currency! You’ll be able to pay in Danish Krone for our subscriptions on all terms, as well as additional SMS credits from here on in.

xkxk

New Alert log feature, Bulk Update improvements, UI changes and API limit changes.

We’ve got a few things to bring you up to speed with today, and you can find all the information below!

New Alert log feature

Our new Alert Log feature gives you a high level of visibility on alerts that have been sent out by our system, you can see the timing, and status of any alert we send no matter the alerting  method.

newblog1

This new feature is available for all plans, so you can take advantage of the data whether you are on our free or Enterprise package! You’ll be given the reasons for any alert failures, some examples including running out of SMS credits and incorrect contact details. As well as a full log of all alerts sent out, with this tool you can also see logs of reports generated by features like Virus Scan.

You can access this new feature by going to the Contact Groups section of your account, and from here you can see the alert logs for each Contact Group on your account.

Bulk Update improvements

We’ve implemented a summary of which tests will be updated upon filtering for all Bulk Updates. This means that each time you run an update in bulk you’ll be able to see which tests were affected to the right side of the page.

blog1two

UI Improvements

First off we’ve made some improvements to the screen which displays all of your tests, primarily the changes are contained within the “Box View” layout, we’ve changed the buttons on the test boxes to be smaller and more accessible, and we’ve ensured that all of the options for each test can be easily accessed without needing to drill down into the test’s details.

We’ve also somewhat standardized the entry system for the email addresses in the Contact Groups to closely match the phone number entry section.

This means now that it will not be possible to miss alerts due to formatting errors, all previous phone numbers have of course been ported over to the new system already!

API Limit Changes

Following user requests we’ve increased the burst limit for our API to 20 per second, up from 10. To accommodate this change and also to prevent abuse in future we have elected to have a daily limit of 100,000 API calls per account – this is a level at which we can see that very few users will be affected, and we feel that it’s a fair limit in terms of using our API on any paid plan. There are no changes to this on the free level plan, and the same limit of 250 calls per day will apply.

BLAHX

New API Key Management function, and team access to data through the API and App

In this post we’ll take you through the available options for managing sub-accounts, from managing permissions in app, to our new functionality which allows you to assign individual API keys to your users. First lets take a look at our new API Key Management feature with support for multiple API Keys.

API Key Management

keyblog1

It’s now possible to add multiple API keys to an account, this means that for teams the same key will no longer need to be shared, and each member of staff/department can be assigned their own access token.

As well as being an improvement security wise, you can monitor the usage for each key in the API Key’s section of the user menu, to do this – and to add new keys for your team simply click here.

Sub-User Management

On our Business level plan it’s possible to add Sub-Users who have access to the in-app data, this allows them to view the information in a much more visual fashion when compared to the API. Sub-Users will be able to view the full settings and details of the tests on the “Main Account” depending on the permissions that they are assigned.

You can assign a few different parameters to your Sub-Users, first off you should decide whether they will have “view-only” or “full-edit” rights which will affect how they can interact with the test data from the main account.

Another handy option that can be set is tag based access, this means that you can assign a Sub-User to one or more test tags, and when they log in it’s only the tests under these tags that they will be able to see and interact with.