Hi @Bombbe ,
If depending on Heartbeat kusto table is not helpful in your use case then the next option would be to
- depend on windows event id i.e., check which event id is being generated just before the VMs go offline and enable collection of such events and then configure alert rule (or)
- depend on custom configuration i.e., create a runbook with Test-Connection cmdlet, schedule it, forward job logs to Azure Monitor and create alert rule for ping failures. For example, refer this blog.
On the other hand, I would recommend to share this use case here as feedback (i.e., feature request to have a built-in metric alert which pings the VM directly without depending on Heartbeat kusto table). In general, Azure product or feature team would check feasibility of a feature request, prioritize against existing feature backlog, add in roadmap as appropriate and would announce and/or update the related Azure document once a feature request is addressed.