Scope ongoing support through Proxmox maintenance or Managed Proxmox.
A Proxmox maintenance contract should identify the systems, included work and incident process. A vendor subscription is separate: it covers repository access and vendor support according to tier, rather than operating your environment (subscription agreement).
As of October 2026. The technical statements follow the linked primary sources.
Contents
- Separate subscription and operations
- Scope checklist
- Distinguish response and recovery
- Define priorities and service hours
- Maintenance calendar: tasks by cadence
- Template for the service description
- Make proposals comparable
Separate subscription and operations
Subscription tiers differ in support coverage and response conditions. Purchasing a subscription or installing updates does not automatically transfer operational responsibility. Review both vendor terms and the service provider’s scope.
WZ-IT offers subscriptions, maintenance and Managed Proxmox as separate entry points. The agreed scope governs the service.
Scope checklist
This checklist supports procurement; it does not describe a standard contract. Record owners, scope, exclusions and evidence for each item.
| Area | Clarify in the contract |
|---|---|
| Inventory | List nodes, clusters, PBS, storage and guest operating systems separately |
| Updates | Approval, maintenance windows, reboots and abort criteria |
| Monitoring | Measurements, alert recipients and handling of alerts |
| Incidents | Reporting channel, service hours, priorities and escalation |
| Backup | Job checks, retention, keys and separate restore tests |
| Changes | Distinguish routine maintenance from projects and expansion |
| Evidence | Change logs, documentation and access inventory |
| Contract end | Handover of configuration, credentials and operational knowledge |
Distinguish response and recovery
A response target concerns the start of handling, not a guaranteed end to an incident. Specify its trigger and required cooperation. Define operational objectives from application requirements rather than deriving them from a subscription name.
A successful backup job does not prove that a business application works after recovery. PBS maintenance documentation separates verification and retention; functional acceptance belongs in a restore test. Check whether this is commissioned and who accepts application recovery and key access.
Define priorities and service hours
Define in the contract which incident has which priority. The definition belongs in the document, not in the provider's usage of words. An example of four levels that you adapt to your applications:
| Priority | Definition | To be agreed |
|---|---|---|
| 1, critical | Production service down, no workaround | Service hours, reporting route, start of handling |
| 2, high | Service severely restricted or redundancy lost | Start of handling, information interval |
| 3, normal | Fault with workaround, partial function affected | Handling in regular service hours |
| 4, request | Question, change request, report | Scheduling, project delimitation where needed |
Service hours (for example weekdays during the day or around the clock) apply per priority and may differ. Also record whether standby is paid and whether response times run from the report or from receipt at the provider.
Maintenance calendar: tasks by cadence
A maintenance contract should name which recurring tasks take place. Structuring by cadence makes the scope verifiable:
| Cadence | Typical tasks | Evidence |
|---|---|---|
| Ongoing | Monitoring, alert handling, capacity alerts | Alert log |
| Monthly | Updates of nodes and PBS, checking backup jobs and verify runs | Change log, job report |
| Quarterly | Restore test of a reference system, capacity and growth review, overview of access and permissions | Restore log, report |
| Yearly | Planning major upgrades and hardware replacement, reviewing recovery objectives, subscription renewal | Planning document |
Which of these tasks are included is determined by the contract. Tasks outside the scope, such as a major upgrade or a migration, are delimited as a project and agreed separately.
Template for the service description
A simple template every provider should fill in. It makes proposals comparable:
Supported systems: <nodes, cluster, PBS, number of guests>
Included tasks: <updates, monitoring, backup control, ...>
Not included: <migration, major upgrade, guest operation, ...>
Service hours P1/P2/P3:<times per priority>
Start of handling: <deadline per priority, reference point>
Restore test: <cadence, scope, log>
Reports: <content, cadence>
Subscription: <tier, procurement, renewal, who opens tickets>
End of contract: <handover of configuration, access, documentation>
Make proposals comparable
Ask providers to address the same inventory and checklist. Mark excluded items explicitly. A price without an operational boundary gives little basis for comparison. At WZ-IT this checklist leads to Managed Proxmox; subscriptions and individual projects should remain separately identified.
Further reading
Relevant service: Managed Proxmox.
