What should I check in a server SLA and maintenance policy?
An SLA is the service agreement’s defined commitment, measurement method and any stated remedy. It can differ from your own application availability target and from a support response-time objective. Read the terms for the exact service rather than importing a percentage or promise from another plan.
Before you start
- The proposed or active service agreement and your application’s availability requirements.
Instructions
1. Understand what is measured
Identify whether availability refers to network reachability, infrastructure, power, a managed service or the end-to-end application. Check the measurement period, monitoring source and start and end of an incident. A healthy host does not establish that a customer can complete a transaction.
2. Review planned and unplanned work
Ask how maintenance is announced, which events are excluded, and whether emergency maintenance follows different notice arrangements. Confirm response, update and restoration expectations separately. Include dependencies, customer changes and third-party software when checking what the commitment covers.
3. Record the applicable process
Keep the agreed terms, escalation route, required evidence and any claim deadline with the service record. In an incident, document timestamps and impact using the approved support conversation. Plan your own redundancy and recovery to meet business needs that exceed the confirmed service commitment.
Check the result
- The team understands the covered service boundary, measurement and escalation process.
- Internal recovery requirements do not rely on an unconfirmed contractual promise.
Troubleshooting
- An uptime graph and an SLA calculation disagree
- Compare the time period, probe location, service boundary and exclusions. Ask support to reconcile the evidence against the applicable terms.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.