Soooo, this page is now +- ready netwatch | RouterOS Manual :0
A full rewrite of the main Netwatch page is currently in progress. We are planning to remove the parameter tables from that page and keep only configuration examples and descriptions, with links to the CLI Reference page where the parameter tables will be maintained from now on.
If you have any ideas for configuration examples that should be added, feel free to share them 
It is much better, though I hate this approach.
If you publish a table, add a column for default and one for probe, things will be much easier to read. (but this is probably just me)
A small thing, but make up your mind, you call the same thing once HTTP/S-GET and once HTTPS-GET.
I insist on the fact that if you list thr- in this order:
| Column 1 | Column 2 |
|---|---|
| 1 | thr-max ( unset ) |
| 2 | thr-avg ( unset ) |
| 3 | thr-stdev ( unset ) |
| 4 | thr-jitter ( unset ) |
| 5 | thr-loss-percent ( unset ) |
| 6 | thr-loss-count ( unset ) |
and then you list the rtt- in this OTHER DIFFERENT order:
| Column 1 | Column 2 |
|---|---|
| 1 | loss-count |
| 2 | loss-percent |
| 3 | rtt-avg |
| 4 | rtt-min |
| 5 | rtt-max |
| 6 | rtt-jitter |
| 7 | rtt-stdev |
you confuse readers:
| Column 1 | Column 2 | Column 3 | Column 4 |
|---|---|---|---|
| 1 | thr-max ( unset ) | 1 | loss-count |
| 2 | thr-avg ( unset ) | 2 | loss-percent |
| 3 | thr-stdev ( unset ) | 3 | rtt-avg |
| 4 | thr-jitter ( unset ) | 4 | rtt-min |
| 5 | thr-loss-percent ( unset ) | 5 | rtt-max |
| 6 | thr-loss-count ( unset ) | 6 | rtt-jitter |
| 7 | rtt-stdev |
this proposed way is much more readable, logic and linear:
| Column 1 | Column 2 | Column 3 | Column 4 |
|---|---|---|---|
| 4 | rtt-min | ||
| 1 | thr-max ( unset ) | 5 | rtt-max |
| 2 | thr-avg ( unset ) | 3 | rtt-avg |
| 3 | thr-stdev ( unset ) | 7 | rtt-stdev |
| 4 | thr-jitter ( unset ) | 6 | rtt-jitter |
| 5 | thr-loss-percent ( unset ) | 2 | loss-percent |
| 6 | thr-loss-count ( unset ) | 1 | loss-count |
but that is just like my opinion, man 
.
Finally, if you write here:
| Column 1 | Column 2 |
|---|---|
| bool (boolean) | values can be true or false. |
You (IMHO) CANNOT (almost everywhere else) write that a bool type has a default of "no" (and thus the "other" value is "yes").
bool is 1/0 or true/false, yes/no is something else
I do not understand this:
The linked data types doc says: can be true or false. What's wrong with that explanation?
Can I say, I want to check a device with 3 pings (ICMP echo requests) or 4, it does not matter.
If at least 1 out of the 3, 4... returns, everything should be okay (stays "UP"). Because I ping a chepo china devcie which is not fast in regads of ICMP.
I was not able to configure Netwatch this way. Does anyone have a working example?
Nothing.
A boolean usually can be true/false or 1/0.
Here specifically it is declared as being true/false in RouterOS.
Then this (example on the netwatch page we are discussing):
| Column 1 | Column 2 | Column 3 |
|---|---|---|
| ignore-initial-up ( unset ) | bool | Specifies if Up script should be run if the probe state change goes from Unknown to Up, used to help against false positives after enabling the probe, or after a reboot. no means that the change from Unknown to Up will not be ignored. (default value: no) |
says that the variable is of type bool and that it has a default setting of no (and conversely its opposite is yes), but the definition of bool is that values are either true or false.
Unless you define it somewhere:
no <> true
no <> false
and then a variable that can have (actually has by default) a value of no is NOT a bool type.
it could be another type, similar to bool, let's say textbool:
| Column 1 | Column 2 | Column 3 |
|---|---|---|
| ignore-initial-up ( unset ) | textbool | Specifies if Up script should be run if the probe state change goes from Unknown to Up, used to help against false positives after enabling the probe, or after a reboot. no means that the change from Unknown to Up will not be ignored. (default value: no) |
IF on the data type page we have:
| Column 1 | Column 2 |
|---|---|
| bool (boolean) | values can be true or false. |
| textbool (boolean) | values can be yes or no. |
That yes/no thing is everywhere in the configuration. disabled=yes/no is one example. When you get the value and assign to a variable and then use typeof: it's bool.
So yes, for me this "yes" and "no" is something like a "natural representation" of the datatype values true and false. 
I know, never said it was a rare case, and it is NOT correct everywhere, IF the variable is declared as type bool that has a different set of values defined.
One could use a pseudo definition like:
| Column 1 | Column 2 |
|---|---|
| bool (boolean) | values can be true or false, or yes or no, depending on context, actually throughout all RouterOS yes/no is largely prevalent. It depends. |
| Word for today: | |
| Rigorous | What the above pseudo-definition definitely isn't. |
"yes"/"no" is still a bool type internally, not a separate type. Now CLI expressions that accept a boolean type do accept =yes/=no but they are "cast"* to bool (*perhaps "boxed"), since a "bool" attribute has a known (boolean) type it can safely case "yes"/"no" but else where there is no such context to know "yes" is bool, so a "yes" need explicit cast outside of a boolean attribute.
The only odd/irregular part WAS [:tobool "yes"] != true... BUT this was fixed in 7.22 ( "console - implemented string casting in :tobool command"), so you can always explictly cast a string like "yes"/"no"/"true"/"false" to the actually bool values: true / false (without quotes).
This seems like the right call, since having tables of potentially stale/wrong attributes is worse.
IDK specific examples, but you should cover all of the netwatch types with at least one example. The more example commands, the better IMO. And the have each of the example do something different in the on-up/on-down/on-test. And examples do help AI agents, since they have confirmed/"gold" command that should work to then adapt from as needed. Determining the right command wholecloth is trickier.
But it's really the potential on-up/on-down/on-test things to cover... so things like adjusting/disabled routing table, :beep, /tool/email, or importantly /tool/fetch as a "reporter" to some NMS, pop in my head. With "fetch" example being more complex, since it needs to show using a /system/script since that's required to use fetch based on policy.
