Simon icon Simon
Flexible server monitoring

Introducing Simon 5!

Simon version 5 is now available. It is a massive update, introducing a much-requested feature: syncing the Simon data between multiple Macs, plus a Simon Status service, a Link Checker filter, improved Find filter, iMessage and Speak Error notifiers, a new app icon, and much more.

Important: please note that Simon 5 requires a minimum of macOS 10.12 (Sierra), and is a paid upgrade from Simon 4. Purchasers since September 1, 2020 automatically get a version 5 license (that also works in previous versions).

Read the Simon What's New page for details.

How do I...?

I bought Simon for the sole purpose of monitoring a membership website. I have no idea how to get it to do that. I could watch the "Authenticated Users" for multiple logins at one time, multiple IPs or any Authenticated User that has used over "X" amount of bandwidth-usually over 1 gig puts up a red flag.
Any of the three would probably be a compromised login.

Any help would be great.

David Sinclair's picture

Re: How do I...?

Those are pretty specific changes. Simon can notify you when any change occurs on a page, or a portion of the page, so if you can add tests to watch relevant portions of a page, it could notify you when one of those portions changes. Or you can get Simon to notify you if some required text isn't present, by using it as the Start text of the Smart Change Detection feature.

If you want something more specific than that, you could use a Script-based notifier for changes. You could write a script to analyze the change text and perform some action if the script determines a compromised login.

I hope this helps.

Uploading a report to an FTP site

Greetings - While there's no problem saving a report to the desktop, I've not been successful getting Simon to upload a new report via FTP. When I capture the FTP session with Wireshark, I see a good login, then the "change working directory"command returns an error. Looking at a trace of an FTP session with Transmit - CWD for the same directory works. I used transmit to put a copy of the report up - thinking perhaps Simon needed all the subdirs there already - no love. Any thoughts would be appreciated -


John Gonder

David Sinclair's picture

Re: Uploading a report to an FTP site

Hmm... I would guess that the most likely issue is a not-quite-correct path in your report settings. Did you remember the "public_html" or whatever base web directory?

Perhaps try a different location.

Can you see what error is returned? That might help.

prob too w/uploading report to FTP

I scripted a very simple report not a day after getting a Simon license and it worked perfectly, no problem uploading to FTP, etc. But yesterday (about 40 days after the fact) it just stopped uploading and nothing will correct the problem. it's not a path issue, and there's no issue w/the target destination. The cache and local files are being created but it simply will not upload. FTP is working fine, no network problems, no system config issues. It's a lab machine in a controlled testing environment. No hardware problems we can find, we just went through it carefully. Running OS 10.4.10 on a mirror-door (867MHz) G4, no apps but OEM/OS installed and Simon on unit.

BTW, site tests are functioning fine, checking services http, https, POP, SMTP, etc. w/no problems.

thank you,

Keith Bumgarner

David Sinclair's picture

Re: prob too w/uploading report to FTP

So it worked fine for a month or so, then stopped working... so what has changed?

Have you upgraded the OS, or added any third-party products, or changed any Simon settings, or any other changes recently?

When weird unexplained things happen, sometimes it indicates a corrupt cache file; I find that deleting the Caches folders in the root and home Library folders often helps when nothing else does.

Re: prob too w/uploading report to FTP

It's a lab testing machine. No 3rd-party apps, only OEM/OS install, only running OS 10.4.10. All network tests check out, no console logs indicate any problems on network such as something occupying the DNSServiceResolver for extended lengths of time (common with simple mail transfers, FTP, other backgrounder uses of tunneled protocols, etc.). One thing would help, namely if Simon offered some kind of feedback or logging as to why something did not work on their site. We pulled the logs from the FTP site where the target directory lives and it does not show even an attempted login. If this is the case, then Simon is dropping the ball somewhere. Since FTP does function on the machine (we loaded the Simon report set from the App Support folder via the FTP function built into the OS) we can't think of anything else. Yes, I agree with you about the caches but not only is this machine stripped of all caches every 72 hrs but we also did a full maintenance routine, including deleting nvRAM, pRAM, directory repairs, and everything else that would constitute a full maintenance turn. EVERYTHING is working perfectly on this machine BUT Simon's report upload function. What is the plug-in relationship to the primary app? Is this some modular, coded function that's "dropped in" at some point or is it fully integrated code and the term "plug-in" is used to denote some separation of function for users conception/perception? Or something else? Any and all help is appreciated.

thank you,

Keith Bumgarner

David Sinclair's picture

Re: prob too w/uploading report to FTP

Sorry for the delay replying; for some reason your reply was marked as spam, so I only saw it by chance. (Perhaps due to everything being in one long paragraph.)

The Report plug-ins are separate code bundles, included within the Simon app bundle. They're written that way to allow enhancing them independently of the Simon app in the future, and to modularize the code. The remote report plug-in actually uses a FTP helper app as well, which is launched when the FTP operation occurs. Maybe something in your machine setup is preventing that from launching?

I do want to add better logging of errors. I plan to add this in an upcoming version.


Thanks, David for getting back to me. We solved the problem by replacing some OS files, seemed to wipe some lower-level stuff clean during a rogue prebinding process (why doesn't Apple fix this horrendous bug?).

Appreciate the comment about adding logging for errors in the future. We love what this app does for us and this would be a great addition. Dead-on w/the development and feature set, fills a big hole in OS X-based systems management.

David Sinclair's picture

Re: thanks

I'm glad you solved it... and it wasn't Simon's fault. :)

I'm pleased that you like Simon so much, too. I have lots of great plans for future versions, so it's going to keep on improving (I hope!).