The Context filter in Simon is a sophisticated filter that takes the previous filter’s input and match range to output some context around that filter’s output text.

It includes controls to specify the maximum number of characters before and/or after the matched range, and/or a delimiter before and/or after the matched range. So for example you can show up to 50 characters, stopping at a line break.

This filter is unusual in that it requires a previous filter to be used, and that needs to be either a Block– or Find-based filter, as those are the only ones that output the needed match range information.

The Context filter uses the Input specified in the test to determine which filter’s input and match variables to use: if you have two previous filters, you can make the Context filter look at the first one by choosing Filter1OutputText instead of the default FilterOutputText (which means the proceeding filter).

The match range is available in variables used by the Context filter, and can be used in your custom filters or notifiers if you wish:

• {FilterMatchLocation}: the position of the match in the input text, e.g. the text between the Blocks, or the Find result. Note that the location is zero-based.
• {FilterMatchLength}: The length of that match.
• {FilterMatchEnd}: The location plus the length, for convenience.

You don’t need to worry about these variables for the Context filter, though; it uses them internally.

Here’s a simple example of this filter in action.

This is from a Web test that looks at the Daring Fireball site. It has a Find Required filter to look for the word “finally”, then if that succeeds a Context filter to output the enclosing paragraph. To round it out, if the Find filter fails, the Override as Unchanged failure case is used, to avoid the test resulting in a failure if Gruber hasn’t used the word “finally” recently.

Below the filters, you can see the Preview pane’s output, which you’ll notice includes the word “finally” towards the end.

I hope this will be a useful filter for many of your tests. Simon is a powerful tool, with lots of other handy filters, services, and notifiers.

I received a customer query asking how to use Simon to check for an expired website SSL certificate.

Of course, Simon is very flexible, so even if there isn’t a built-in service for this specific case, if you can do it in the Terminal, you can probably create a custom script-based service in Simon to do it, too.

There are a number of ways to get certificate information, but this is one simple approach (if you know of a better way, let me know!).

I created a new script-based service, using the basic C shell, a one-line command, and a custom variable for the host name:

I then created a new test using this service. When accessing a server with an expired certificate, the output includes a “verify return code” message of “certificate has expired“, so I used a Block filter to look at just that text (I pasted “Verify return code: ” in the Start text, and an Option-Return in the End text), then a Find Required filter to make the test result in a failure if it doesn’t find “ok“, and finally an Override Custom filter if a failure, to output the error message:

For the success case, the last filter doesn’t apply, so it just outputs the “ok”:

Want to use this service? You can easily add it yourself, or import it by downloading from the Simon Extras page.

I hope you found the techniques in this post helpful.

Dejal Simon is a powerful and flexible website & server monitoring tool. One of the reasons it is so flexible is that in addition to the many built-in services, filters, notifiers & reports, you can extend it by using or writing custom scripts (or port sessions).

Simon comes bundled with many examples of such scripts; check out the Services, Filters & Notifiers lists and look for the items with a “Script” subtitle. You can inspect and edit those to customize them to suit your needs, or use them as inspiration for your own.

As an additional resource, the Simon site has an Extras page, which lists several more scripts that customers have contributed over the years. Some of which have later been bundled with the app, but some are only available there.

If you create or modify a script that others might find useful, please share it! Send me an email with the script attached, along with a description, and I’ll be happy to add it to the Simon Extras page.

The Simon Extras page is organized by feature kind: Service Scripts, Filter Scripts, Notifier Scripts, Report Templates, and Other Goodies (including a way to add multiple tests, an extended siren sound, and a script to monitor a FTP site). There’s also info for developers on writing custom plugins.

Installing scripts is easy:

1. Decompress the downloaded archive, if you browser didn’t do it for you;
2. Launch Simon if not already running;
3. Go to the Services or Notifiers list, as appropriate;
4. Click the New toolbar button (or via the File menu);
5. Choose the Service Kind (or Notifier Kind) button to show the service (or notifier) page.
6. Choose the Script service/notifier kind, if not selected by default.
7. Click the Open Script… button and choose the script file.

The script is copied into Simon, so there’s no need to keep the downloaded file around after loading it.

The Simon app has pages for filters, notifiers, reports and auto pause times while editing a test. These can be reordered very easily, by dragging them to the desired order.

The order really only matters for filters, since subsequent filters can refer to the output of previous ones, though others might look better in a custom order.

Simply click and drag anywhere outside a control to move a filter etc to a new position.

Here’s a looping video example:

I’ve had a couple of queries about checking if a notifier is working, so that seemed like a good blog topic.

Simon is a powerful app. One of its many features is the ability to create custom notifiers, the mechanism for informing you of changes or failures on the tests. Naturally, when you configure a new notifier, or edit an existing one, you want to make sure that it is set up correctly.

This can be done very easily. When showing the Notifiers list, you can simply select the notifier you want to check (as you probably already have if you’re editing one), and click the Reload button in the toolbar, or choose the File ▸ Notify Now menu command.

The selected notifier will then be used, just like when used with a test, except that placeholder values will be used for any variables (since there isn’t a test in this case).

For example, here’s a Notification Center notification, showing placeholder values: