Resolved Bug report: Watchdog disk threshold alert email contains literal placeholders instead of values

[Zenon]

Server operating system version

Debian 12.15 x86_64

Plesk version and microupdate number

Obsidian 18.0.79.6 (build 2026/08/10, revision e72b2a625b7155e90dde0af0efc1c2d0d38b7df0)

Environment​

• Plesk: Obsidian 18.0.79.6 (build 2026/08/10, revision e72b2a625b7155e90dde0af0efc1c2d0d38b7df0)
• OS: Debian 12.15 x86_64
• Watchdog extension: 3.1.10-15879
• Monit: 5.33.0 (distribution package, dpkg -l monit → 1:5.33.0-1)

Problem description​

The email alert sent by Watchdog when a disk usage threshold is reachedcontains unresolved placeholders <fs_size> and <used_size> instead ofthe actual numeric values. The other template fields (Device name, Mountpoint) are populated correctly.

Email received:​

Disk space usage has reached the specified threshold on host [SERVER_HOSTNAME]:
Device name: /dev/vda1
Mount point: /
Capacity: <fs_size> kilobytes
Used disk space: <used_size> kilobytes

Expected content (matching the historical Watchdog format, confirmed in​

Plesk forum threads dating back to 2008):



Disk space usage has reached the specified threshold on host [SERVER_HOSTNAME]:
Device name: /dev/vda1
Mount point: /
Capacity: 123679096 kilobytes
Used disk space: 50388404 kilobytes

Diagnostics performed​

1. Confirmed that Postfix/SMTP is working correctly (the email is delivered;the issue is only with the message content).
2. Confirmed that Monit has correct, complete data for the partition:

$ monit status | grep -A 15 "vda1"
Filesystem 'dev/vda1'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
filesystem type ext4
filesystem flags rw,relatime,discard,errors=remount-ro
permission 660
uid 0
gid 6
block size 4 kB
space total 117.9 GB (of which 4.1% is reserved for root user)
space free for non superuser 65.1 GB [55.2%]
space free total 69.9 GB [59.3%]
inodes total 7856128
inodes free 7601248 [96.8%]


$ df -T /
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/vda1 ext4 123679096 50388404 68226904 43%

Additional test: full uninstall and reinstall of the extension​

To rule out the hypothesis of a leftover inconsistent state from a previousextension update (cf. EXTPLESK-13679), the Watchdog extension was fullyuninstalled via Extensions > My Extensions > Uninstall, then reinstalledfrom the Extensions Catalog, and disk monitoring was reconfigured fromscratch for the /dev/vda1 partition with the same threshold.


Result: the issue occurred identically on the freshly installedextension. The email still contains unresolved <fs_size> and<used_size> placeholders. This rules out a corrupted/leftover local stateas the cause and points to a systematic bug in the Watchdog 3.1.10-15879code itself (or in how it communicates with Monit 5.33.0 on Debian 12),rather than an artifact of this particular installation's update history.

Possible connection to Plesk Obsidian 18.0.79​

The issue appeared on a server updated to version 18.0.79.6. The changelogfor this version (and neighboring microupdates) includes fixes in a relatedarea — disk usage display/calculation and Watchdog's internal state afteran update:

• PPPM-15422 — "Fixed the issue where the mail account disk-usage bar wasmissing after the update to Plesk version 18.0.79."
• EXTPLESK-13679 — "Fixed an issue where, after updating the Watchdogextension to the latest version, obsolete cron entries and scriptsrelated to the extension's earlier version were not properly removedfrom the server."

It is not confirmed that this is the same underlying mechanism as thefs_size/used_size issue described here, but the timing and thematicoverlap (disk usage + Watchdog state after update) suggest a possibleconnection worth investigating.

Conclusion​

Since Monit correctly reports the partition size data, but Watchdog stillfails to substitute it into two specific template fields (fs_size,used_size), the issue lies in the layer of Watchdog responsible forfetching/mapping size data from Monit into the notification email content —most likely a mismatch between the data format returned by this specificMonit version/build and what the Watchdog code expects.

Steps to reproduce​

1. Install Watchdog 3.1.10-15879 on Debian with Monit 1:5.33.0-1(distribution package).
2. Enable disk monitoring for any partition.
3. Temporarily lower the usage threshold below the current usage.
4. Wait for the email alert (default polling interval: 5 minutes).
5. Observe the unresolved placeholders in the email content.

 

[Sebahat.hadzhi]

Hi, @Zenon. Thank you for the report. I was able to replicate the behavior and opened an internal task for our team to check further. I will follow up with more details as soon as possible.

 

[Zenon]

Hi @Sebahat.hadzhi,

Thank you very much for the quick update. I’ll wait for further information.

BR
Zenon

 

[Sebahat.hadzhi]

Zenon, the behavior was registered as a bug identified with ID EXTPLESK-14223. As of the moment, I cannot provide an ETA for the fix or a workaround for the issue. I will follow up with more details as soon as possible. Thank you for bringing our attention to the issue.

 

[Sebahat.hadzhi]

@Zenon , the behavior with the placeholders in Watchdog notifications has been fixed in Plesk Obsidian 18.0.81:

Fixed an issue where the disk usage threshold notification email sent by the Watchdog extension showed the <fs_size> and <used_size> placeholders instead of the actual capacity and used disk space values. (EXTPLESK-14223)

Thank you again for bringing our attention to the issue.

 

[Zenon]

Hi @Sebahat.hadzhi,

Thank you for update, I'll check.

BR
Zenon

 

[Zenon]

Hi @Sebahat.hadzhi ,

I've checked.
Unfortunately, after upgrading to Plesk Obsidian 18.0.81.0, the issue still occurs identically:

Device name: /dev/vda1
Mount point: /
Capacity: <fs_size> kilobytes
Used disk space: <used_size> kilobytes

I dug into the Watchdog database (/opt/psa/var/modules/watchdog/watchdog.sqlite3)and found the root cause is likely deeper than the notification template itself:


sql
sqlite3 -header -column watchdog.sqlite3 "SELECT id, datetime(time, 'unixepoch') as ts, device, mount_point, fs_size, used_size FROM module_watchdog_disk_event ORDER BY time DESC LIMIT 5;"

id ts device mount_point fs_size used_size
-- ------------------- --------- ----------- ------- ---------
5 2026-09-16 08:32:38 /dev/vda1 /
4 2026-09-16 08:00:53 /dev/vda1 /
3 2026-08-25 12:03:40 /dev/vda1 /
2 2026-08-13 08:27:53 /dev/vda1 /
1 2026-08-13 08:26:43 /dev/vda1 /

Every single row in module_watchdog_disk_event, including row #5 which was created after upgrading to 18.0.81, has NULL values in the fs_size and used_size columns. This is despite monit status reporting correct, complete size data for the same partition at the OS level:



$ monit status | grep -A 15 "vda1"
Filesystem 'dev/vda1'
...
space total 117.9 GB (of which 4.1% is reserved for root user)
space free total 69.9 GB [59.3%]

This suggests the fix addressed the notification template's handling of these fields (e.g. no longer crashing or misrendering on a NULL value), but the actual root cause remains: whatever process writes new rows into module_watchdog_disk_event never captures or stores the filesystem size values in the first place, even on a freshly upgraded 18.0.81 install. The notification email is only ever going to be able to show what's in that table, so as long as these columns are written as NULL, the placeholders(or now, presumably, empty values once actually not misrendered) will never contain real data.


Could you check the code path responsible for inserting rows into module_watchdog_disk_event (likely triggered by parsing Monit's disk-threshold event) to see why fs_size/used_size are never populated, even though Monit itself has the correct data available at the same moment?


Environment:
- Plesk Obsidian 18.0.81.0,
- Debian 12.15,
- Watchdog 3.1.0-debian.12.260811.0955,
- Monit 5.33.0.

BR
Zenon