> but seriously, does nobody else see a problem with your monitoring configuration being hosted on the site being monitored?

So, if the file is unreachable, something is probably very very wrong.

Malicious changing of the file could be addressed by firing an alarm when the file changes.

> It is a bit like asking a hospital patient to keep an eye on his own charts and to let you know if anything goes wrong ..

No, it's a bit like leaving the chart with the patient, trusting that he won't destroy it.

> do people really switch monitoring companies often enough to justify having a standard configuration format?

Do people really switch monitoring companies rarely enough to justify keeping a myriad of incompatible configuration formats?

This also has the benefit of you owning all of your own data.

> ps. cucumber syntax is horrible because it perpetuates a 'everybody speaks english' view of the world

Cucumber syntax is great because a lot of people are already used to it. Oh, and it's completely language independent too. https://github.com/cucumber/cucumber/tree/master/examples/i1...

Seems like a service would want/need to cache older versions of monitors.txt, and continue running them for some configurable persistence period before accepting a missing/new/possibly-malicious monitors.txt as giving a true read.

Lol yes I'll add something on this to the site...

My thoughts are the monitoring provider would keep a copy of monitors.txt and work from that, and check for changes regularly. If they can't get to monitors.txt that would trigger an alert.

It is meant to be used mostly as a configuration tool for the monitoring host. If the developer has recently updated/deployed then they are probably working on the site and can ensure monitors.txt is available.