Disclosure: I work on FoxBox, an on-premises SMS gateway. This is a documentation-based configuration note, prepared with AI assistance, not a claim of a tested Proxmox/FoxBox deployment.
For SMS alongside existing email alerts, a useful design is:
Proxmox notification matcher -> dedicated SMTP target -> local email-to-SMS gateway -> SIM
The practical part is deciding which events deserve a short, actionable message. Here is a starting configuration and a validation plan.
1. Create a dedicated SMTP target under Datacenter -> Notifications. Enter the relay hostname, port, encryption mode, permitted sender and recipient address agreed with the mail/gateway administrator. Keep credentials in the protected target configuration; do not put them in a forum post. SMTP targets send directly and do not provide a queue/retry mechanism. If queuing is required, evaluate a properly configured sendmail/MTA route instead.
2. Add a matcher for the new target. For failed backups, the documented criteria are type=vzdump and severity=error, combined with match-all. Check that the backup job uses the notification system: legacy-sendmail bypasses these matchers. A successful target test alone does not establish that the intended job event will match. See the official notification documentation source.
3. At the email-to-SMS boundary, allow only the intended senders and map recipients deliberately. For FoxBox, the documented options include local Postfix/catchall processing and remote IMAP/POP mailbox polling. The latter adds a dependency on that mailbox service. The exact recipient-address rules belong to the local configuration; there is no universal address to paste. Email-to-SMS documentation.
4. My suggested message policy is: system label, event type, short reason and a reference to the full incident details. Avoid copying full backup logs into SMS. Decide in advance whether recovery messages are needed and how repeated alerts will be limited. Those are design choices to implement and verify in the selected mail-processing path, not features established by this note.
5. Validate in an isolated environment with an SMTP sink and SMS transmission disabled. Exercise a matching failure, a non-matching success and duplicate events. Confirm the expected routing and rendered text. This validates mail/routing behavior only; it does not prove modem, carrier or handset delivery.
For an outage use case, draw the dependency path first. A local SMTP/SIM path can remove the external mail-service dependency, but still needs the event source, LAN, gateway power, working SIM and cellular coverage. If Proxmox itself cannot emit an event, a separate monitor is needed. An SMS being accepted by a gateway is also different from delivery or operator acknowledgement.
For SMS alongside existing email alerts, a useful design is:
Proxmox notification matcher -> dedicated SMTP target -> local email-to-SMS gateway -> SIM
The practical part is deciding which events deserve a short, actionable message. Here is a starting configuration and a validation plan.
1. Create a dedicated SMTP target under Datacenter -> Notifications. Enter the relay hostname, port, encryption mode, permitted sender and recipient address agreed with the mail/gateway administrator. Keep credentials in the protected target configuration; do not put them in a forum post. SMTP targets send directly and do not provide a queue/retry mechanism. If queuing is required, evaluate a properly configured sendmail/MTA route instead.
2. Add a matcher for the new target. For failed backups, the documented criteria are type=vzdump and severity=error, combined with match-all. Check that the backup job uses the notification system: legacy-sendmail bypasses these matchers. A successful target test alone does not establish that the intended job event will match. See the official notification documentation source.
3. At the email-to-SMS boundary, allow only the intended senders and map recipients deliberately. For FoxBox, the documented options include local Postfix/catchall processing and remote IMAP/POP mailbox polling. The latter adds a dependency on that mailbox service. The exact recipient-address rules belong to the local configuration; there is no universal address to paste. Email-to-SMS documentation.
4. My suggested message policy is: system label, event type, short reason and a reference to the full incident details. Avoid copying full backup logs into SMS. Decide in advance whether recovery messages are needed and how repeated alerts will be limited. Those are design choices to implement and verify in the selected mail-processing path, not features established by this note.
5. Validate in an isolated environment with an SMTP sink and SMS transmission disabled. Exercise a matching failure, a non-matching success and duplicate events. Confirm the expected routing and rendered text. This validates mail/routing behavior only; it does not prove modem, carrier or handset delivery.
For an outage use case, draw the dependency path first. A local SMTP/SIM path can remove the external mail-service dependency, but still needs the event source, LAN, gateway power, working SIM and cellular coverage. If Proxmox itself cannot emit an event, a separate monitor is needed. An SMS being accepted by a gateway is also different from delivery or operator acknowledgement.