2 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	4639ac6e52	fix(monitors): a ping or TCP check times the network, not Steward (#6105) ... response_ms was the whole `ping -c 1` process, or an open_connection awaited on the event loop: about 15 ms on a LAN whose round trip is under 1, and every host read slow together whenever Steward was busy. A ping now reports the round trip ping itself printed (the elapsed time only if it printed none); a TCP connect is timed in a thread, the name resolved first and not counted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-19 15:38:17 -04:00
bvandeusenandClaude Opus 5.5	ca12652277	fix(monitors): a failed ping or TCP check says why (#5430) ... tcp_check swallowed every exception and icmp_check returned on a non-zero exit without a reason, so every down ICMP/TCP monitor stored error_msg NULL and the Monitors page and MCP showed it down with no why. Each failure now names its cause: "No reply within 2 s", "Connection refused on port N", "No answer on port N within 5 s", "Can't resolve <name>: ...", the OS error, or ping's own first stderr line. An ICMP check that fell back to TCP says so, and a ping that outlives its timeout is killed rather than left running. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-08 21:49:42 -04:00