Here’s a fun example of using Simon for a purpose that may not be entirely obvious.

My wife and I had a big trip to Yellowstone National Park coming up, so I was curious about what the traffic was like to get into the park.

Conveniently, Yellowstone has a number of webcams that watch the park, including the west entrance gate, where we’d be entering.

So I thought I could leverage Simon to help me watch it over time — rather than keeping the web page open and watching it throughout the day, I can have Simon capture the webcam images to a local folder, then review at my convenience.

To find the URL of the webcam image, I used Safari’s web inspector:

Then I added a custom service to Simon to download the webcam images to a folder:

That uses the curl command line tool to download the image and save to a local folder; the `date -v+1H +%Y%m%d%H%M%S` part of the path outputs the date and time in the format YYMMDDHHMMSS, adding one hour from my local time zone, since Yellowstone was an hour ahead of me at the time.

To schedule the captures, I added a test in Simon that checks once per minute, using that service. No filters or notifiers needed.

That results in a folder in the Finder with files like this:

I can arrow through them to quickly view them. And I can also do other things, like use the excellent Retrobatch app to convert them to a GIF:

Click to view an example of the resulting GIF, showing the traffic flow from 06:00 to 18:00 on one day (the GIF is 61 MB, despite being scaled, so might take a moment to load); each frame of the GIF represents one minute, six frames per second:

That seems typical; it gets really busy around 06:30, and eases off around 12:30 every day. So a tip for Yellowstone visitors; enter in the afternoon! Of course, that really only works if you’re staying in the park, since it takes ages to get anywhere in the park. It’s a big place.

If you’re curious, I did several posts about this Yellowstone trip on my Sinclair Trails blog. Check it out!

One of the major strengths of Simon, my website and server monitoring tool, is the flexibility it offers through the ability to write custom scripts in many scripting languages. Simon is plenty useful with the built-in services, filters, and notifiers, but the ability for customers to enhance it themselves makes it even better.

There are several script-based services, filters, and notifiers built in to the app, and others can be downloaded from the Simon Extras page.

One such example is the Show & Screenshot notifier script (click that link to download it). To install it, go to the Notifiers page in Simon, add a new notifier, choose Script for the notifier kind, click the Open Script… button, and choose the downloaded script.

This script simply opens the page in the default web browser, waits a few seconds for the page to render, then takes a screenshot of it. By default it’ll wait 10 seconds, and save to the Desktop, but you can customize those values; enter the path of a folder to save them to (the folder must already exist). Also specify how long to wait before performing the screenshot, in seconds:

And of course to use the notifier, specify it in the Notifiers page of a test:

Note that when this notifier is first used, macOS will ask for permission to capture the screen; until you grant that, it’ll capture an empty desktop.

Check out the Simon Extras page for other scripts. And if you create a useful script for Simon, please share it with others!

As you know, Simon is a website and server monitoring tool. This mouthful is to try to describe two of the levels at which Simon operates. At the very basic level, Simon is a very simple utility to watch web pages, and let you know when they change or go down. But Simon has much more depth to it — it enables you to monitor all sorts of internet servers and services, local applications, disk volumes, and more.

The Preview pane has this duality, too. When used with a web-based test (i.e. one using the Web Page service), it displays the rendered web page and graphics on the left (which can be interacted with like in a web browser), and the HTML source, web page headers, and filter output on the right:

This is really handy, both to quickly see the page while in Simon, without having to switch to a web browser (which is easy too, via the File ▸ Visit Site command), and when setting up the test in the first place.

The service and filter output are useful, too; you can see the HTML (or other) output, and the output of each filter.

The filters are one of Simon’s key features. This is a page of the test editor, where you can tell Simon to only look at the HTML source between two blocks of text, or find required text, or evaluate numbers, or reformat text, and much more. This enables you to focus on the part of the page you care about, and avoid dynamic portions like banner ads etc. You can easily set this up via the Preview window. With the test editor open, after entering the URL, show the Preview to display the preview of the page. Then search through the HTML source for interesting portions of the text (click in the HTML then press ⌘F to find text), select it, copy the relevant text, and paste into filter fields.

For example, here’s Apple’s RSS feed, with filters to extract and format the title and body text of the latest news:

As useful as this is, it’s not done yet. The Preview is also supported by many other services, in a slightly different way. For non-web services, the Preview looks much the same, but without the rendered content. Instead of the HTML source, it shows the output of the service. This is all plain text, since that’s what these services deal with.

For example, here’s the preview of a Ping test:

These services support the filters, too: just like with web pages, you can use filters to analyze the output and extract interesting nuggets.

I hope you’ll use the Preview to good advantage when configuring and using Simon.

A useful feature of Simon is how it handles the situation when your computer loses its internet connection.

People sometimes ask me what Simon does in this situation, concerned that it would count as a failure for tests. Simon is smarter than that, though. Every time it starts a check, it first checks if the computer has a current internet connection, and only then performs the check.

If it determines that your internet connection has been disrupted, it places the test in an “offline” state, where it shows a blinking “lightning bolt” for the status icon until the connection is restored. This offline state doesn’t count as a failure (or success).

Simon works out if you have a connection by seeing if it can resolve one of two popular domain names; if either work, your connection is probably fine, but if both fail, it is likely disconnected. Using two domains avoids a temporary outage of either one.

You can disable this internet connection check on a per-test basis via the Can check when offline checkbox on the test editor’s Options page. This is useful if you want to create a test to notify you when your connection goes down, or for tests that don’t require an internet connection (e.g. using the Application or Script service kinds):

I sometimes receive a question from a potential customer, asking whether Simon has the ability to send a notification via email.

Although I do mention it in a number of places, this isn’t an unreasonable question, particularly if you just download Simon and start playing with it, as no email options appear in the list of available notifiers in the Edit Test pane by default.

Why is this? Because unlike the Speech and Sound kinds of notifiers, the Email one requires some configuration before it can be used, so it can’t be offered by default.

The way notifiers work is (I hope) pretty intuitive, but a little indirect. Simon provides a number of notifier kinds that do the work of notifications, and you configure notifiers to use those, then choose notifiers for each test.

These levels of abstraction allow easy re-use of notifiers: a single kind of notifier can be used by multiple notifiers, and a single notifier can be used by multiple tests, without having to set up the same things over and over again.

For example, you can add a notifier to email yourself for some failures, another email notifier to your clients for other failures, another one for recoveries, and so on, and use whichever ones of those are desired in tens or hundreds of tests, as required, as simply as choosing them from a pop-up menu.

So, as I said, there is no email notifier set up by default, since it needs configuration, but you can easily add one. If you’re editing a test and realize that you want to receive an email when this test changes, fails, and/or recovers, you can click the New Notifier… button in the Notifiers section of the Edit Test pane, which will switch to the Notifiers page, and start editing a new notifier. You can then choose Email from the Notifier Kind pop-up menu, and the controls below will change to those for an email, with a sample email pre-populated, which you can edit as desired:

You can then configure the email To etc fields, plus switch to the Name page to give the notifier a name, and perhaps the Options page to indicate whether this notifier is available for changes, failures and/or recoveries.

Once it all looks good, click Done to save the notifier. You can check that it is set up correctly by choosing the File ▸ Notify Now menu command; that will send an email with placeholder values. If you don’t receive the email, check the notifier settings.

The new notifier will then be available for that test and any others you want to use it in:

Easy!