Assuming this client is tying into a hosted database, the simplest way is for the client to set a timestamp corresponding to the last time it finished the script, perhaps in a separate table that records each run. Then you can check that log to see if too much time has elapsed.
If it's not a hosted system, then you'll need to do it at the OS level. You can run a Scheduled Task (on Windows) or a chron job (Mac) to launch the local database. I know on Windows, if you launch a task while it's already running, nothing additional happens.
You can couple this with a separate window in the application that runs an OnTimer script.
If that doesn't suit, then maybe a little more detail about your setup would help with a better answer.
Actually, I was thinking more along the lines of how could I have typical external monitoring systems, say like a Nagios, Monitis or DataDog, keep an eye on a FMP client? Has anyone ever done something like this, and if so, what did you do?
If you want to go that sophisticated, why not let FMS scheduled tasks take care of whatever the robot does? Then you can just monitor FMS which is easier to do than trying to monitor a client...
If you must use a client machine then have it also open (and host) a dummy file so that you can check if something is listening on port 5003. That won't tell you if your robot file is doing its job though. Mike's suggestion about having the robot write to a log file would work for that. On windows you can even have it write to the Windows event log which is something that most monitoring tools can work with.
If you have web publishing enabled, you can also check the xml interface to see what databases are hosted.
Note that this only works if the ports are open, web publishing is on and you may also need authentication if that is enabled to see hosted files.
I did this same thing a number of years ago. We set up a "robot" client to run reports and other repeating tasks that would otherwise tie up someone's computer for too long, or weren't appropriate for the server's scheduled tasks - because of plugin limitations.
There were several pieces to our solution, but it was very robust.
It involved auto-booting the computer, with an auto-login to a limited-permission account.
I used a Launch Agent or Launch Daemon, I forget which, to start FileMaker and run an infinitely looping script, which was monitoring a work queue. The Agent was set to auto-respawn if the FileMaker process ever quit. The Script being run was also updating a heartbeat file with the name of the currently running job, among a few other bits of information.
On the same machine, there was a cron job that was executing a perl script that I wrote that was monitoring the heartbeat file. If it wasn't being updated regularly, the perl script would check if the Filemaker server was alive (in case there was a network issue) and kill the local FileMaker thread if too much time had elapsed since the last heartbeat. In addition, if there was no heartbeat file, the Perl script would reboot the workstation, starting the whole process over again. All along the way, the perl script was sending status emails to myself, letting me know of pending actions.
The only weak link in the whole solution was if we experienced a power outage, in which case, we had bigger problems to worry about.