Container monitoring - check status of OOMkilled and report/notify #4607

New issue

Open

opened 2026-02-28 04:09:02 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 04:09:02 -05:00

Owner

Originally created by @psyciknz on GitHub (Jan 13, 2026).

n/a

🔖 Feature description

Would it be possible to report of if a container, while running, is reporting OOMKilled? This is when it's run out of memory from what has been allocated.

It is available as part of the .State tree of a container.

✔️ Solution

Read the state of a container and fire a notification, or set a state for the container as unhealthy if it is reporting that it has been restarted after hitting an OOM (Out of memory) state

❓ Alternatives

No response

📝 Additional Context

Looking at the JSON that seems to be pulled, it looks like it's the equivalent of what is returned for docker inspect. So the OOMKilled value exists as .State.OOMkilled

Originally created by @psyciknz on GitHub (Jan 13, 2026). ### 📑 I have found these related issues/pull requests n/a ### 🔖 Feature description Would it be possible to report of if a container, while running, is reporting OOMKilled? This is when it's run out of memory from what has been allocated. It is available as part of the .State tree of a container. ### ✔️ Solution Read the state of a container and fire a notification, or set a state for the container as unhealthy if it is reporting that it has been restarted after hitting an OOM (Out of memory) state ### ❓ Alternatives _No response_ ### 📝 Additional Context Looking at the JSON that seems to be pulled, it looks like it's the equivalent of what is returned for docker inspect. So the OOMKilled value exists as .State.OOMkilled

deekerman added the

feature-request

A:monitor

type:enhance-existing

labels

2026-02-28 04:09:02 -05:00

deekerman commented

2026-02-28 04:09:05 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 14, 2026):

I did not know if I should include this as a DOWN-trigger so left it out.
Not sure what is the correct handling here..

@CommanderStorm commented on GitHub (Jan 14, 2026): I did not know if I should include this as a `DOWN`-trigger so left it out. Not sure what is the correct handling here..

deekerman commented

2026-02-28 04:09:07 -05:00

Author

Owner

@psyciknz commented on GitHub (Jan 14, 2026):

I did not know if I should include this as a DOWN-trigger so left it out. Not sure what is the correct handling here..

oh had you looked at ?
Is there an unhealthy state that isn't down, or the concept of a warning state for a monitor? Because it's technically not down, but being able to get a notification for it, or any in that state would be the use case.

@psyciknz commented on GitHub (Jan 14, 2026): > I did not know if I should include this as a `DOWN`-trigger so left it out. Not sure what is the correct handling here.. oh had you looked at ? Is there an unhealthy state that isn't down, or the concept of a warning state for a monitor? Because it's technically not down, but being able to get a notification for it, or any in that state would be the use case.

deekerman commented

2026-02-28 04:09:07 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 14, 2026):

We currently don't have such a state. We have UP, DOWN and PENDING (could also be renamed CURRENTLY_RETRYING_DOWN_HEARTBEAT).

For other things like domain expiry or certificate expiry we have the ability to send messages, but this seems a bit too noisy for this (if one monitor OOMs, likely others are also OOM-ing).

@CommanderStorm commented on GitHub (Jan 14, 2026): We currently don't have such a state. We have `UP`, `DOWN` and `PENDING` (could also be renamed `CURRENTLY_RETRYING_DOWN_HEARTBEAT`). For other things like domain expiry or certificate expiry we have the ability to send messages, but this seems a bit too noisy for this (if one monitor OOMs, likely others are also OOM-ing).