The "Proxmox VE by HTTP" OOTB template includes an "LXC discovery" and a "QEMU discovery" with the following trigger prototypes:

LXC

Name: Proxmox: LXC {#NODE.NAME}/{#LXC.NAME}: has been restarted
Expression: last(/Proxmox VE by HTTP/proxmox.lxc.uptime{#LXC.ID})<10m

QEMU

Name: Proxmox: VM {#NODE.NAME}/{#QEMU.NAME}: has been restarted
Expression: last(/Proxmox VE by HTTP/proxmox.qemu.uptime{#QEMU.ID})<10m

In both cases, the trigger identifies and generate an event when a discovered LXC/VM has an uptime of less than 10 minutes. However, there is a potential issue with this approach that could to be addressed.

The issue arises when the item "Proxmox: LXC/VM {#LXC.NAME}/{#LXC.NAME}: Status" captures the LXC/VM's raw status, which includes the uptime even when it is stopped. In such cases, the uptime value remains at zero, causing the trigger expression to generate an event that won't be resolved.

To mitigate this issue, it is good to perform a status validation before generating the event. This validation should check the status of the LXC/VM and prevent the trigger from generating events for stopped instances.
A simple status check should suffice. By incorporating this validation, the trigger will only generate an event when the LXC/VM is genuinely restarted and not when it is stopped.

Here's a suggested version of the trigger expression that includes the status validation:

LXC:

last(/Proxmox VE by HTTP/proxmox.lxc.uptime[{#LXC.ID}])<10m
and
last(/Proxmox VE by HTTP/proxmox.lxc.vmstatus[{#LXC.ID}],#1)="running"

QEMU:

last(/Proxmox VE by HTTP/proxmox.qemu.uptime[{#QEMU.ID}])<10m
and
last(/Proxmox VE by HTTP/proxmox.qemu.vmstatus[{#QEMU.ID}],#1)="running"

With this modified expression, the trigger will only fire when the LXC/VM has an uptime of less than 10 minutes and its status is "running," ensuring that events are generated and resolved accurately.