Hello, the configuration plans can do a ton of great things, but they're a bit confusing -- and a big thing we want to be improving in the next year, with both software and documentation changes.
But I'll explain a couple things you might already know, for the sake of helping someone who might read this in future. Using your first script (without the execution policy):
The OtterScript is executed twice in a row; first in "Collect" mode then "Ensure" mode if it
Ensure-File always executes in Collect (and it records whether the file exists), and it may execute in the "Ensure" run (where it would create/overwrite) if it reported drift
Start-Service never executes in Collect, but may run in "Ensure" mode... but may executes if another operation in the block reported drift (i.e. if Ensure-File reported drift)
Post-Http never executes in Collect mode, and it never executes or Ensure modes, because it's the only statement in a block
The with executionPolicy=always policy changes this, and it's the intended use of this execution directive. But... it's an editor bug, so we'll fix it.
So... all that said... I don't think I'd recommend doing an error handling in a Configuration plan like this; it feels more appropriate for an Orchestration plan that you run for a purpose, to like provision or set-up a server.
Otter will perform a routine configuration scan at least every hour, so there's a good chance this will just end up sending the same error message over and over:
Drift is a detected
Configuration FAILS to change
Error notice is sent
This isn't all that helpful, and is more of an indication of an outage more than anything else. And this isn't a great way to detect an outage. Instead, you can check the status of the server; if there is a failure during a Configuration execution, the server status becomes Error, and it can then be investigated about the details.
