Custom System SLA Checklist: What to Agree Before Go-Live

When a new website, portal, dashboard, or internal web app goes live, the focus is usually on features, design, and launch dates. But once employees, customers, or partners start depending on the system, a different question becomes urgent: who is responsible when something breaks, slows down, needs an update, or requires urgent support? This is where a clear Service Level Agreement (SLA) protects both your business and your technology partner.

An SLA does not need to be complicated. For Saudi and Gulf businesses, it should be a practical document that explains how the system will be supported after launch, what response times are expected, how backups are handled, and how change requests are managed. The best time to agree on these points is before go-live, not during the first incident.

1. Define What “Uptime” Really Means

Many business owners ask for “high uptime,” but that phrase is too vague unless it is defined. Uptime should explain when the system is expected to be available, what is excluded, and how availability will be measured.

For example, a public customer portal may need stronger availability than an internal reporting dashboard used during office hours. A marketing website may tolerate short planned maintenance windows, while an order management system may require more careful scheduling.

Before go-live, clarify these points:

• Which parts of the system are covered by the SLA: website, admin panel, API, database, integrations, hosting, or all of them?
• Is uptime measured monthly, quarterly, or another way?
• Are planned maintenance windows excluded from downtime?
• Are third-party services excluded, such as payment gateways, SMS providers, maps, or government integration services?
• Who monitors availability and how are alerts received?

This matters because many custom systems depend on services outside the developer’s direct control. If a payment provider, hosting platform, or external API fails, the SLA should explain how your technology partner will investigate and communicate the issue, even if they cannot directly fix the third-party service.

The goal is not to promise perfection. The goal is to remove confusion when availability affects operations.

2. Agree Support Hours, Severity Levels, and Response Times

Support expectations are often misunderstood. A manager may assume that “support included” means immediate help at any time, while the development team may mean support during working hours for normal issues. This gap can create frustration after launch.

Your SLA should define support hours clearly. For example, support may be available during Saudi business hours, extended evening hours, weekends by agreement, or 24/7 for critical systems. The right model depends on how the system is used.

It should also define incident severity levels. A simple structure is usually enough:

• Critical: The system is down, customers cannot complete key actions, or a major business process is blocked.
• High: A key feature is failing, but there is a temporary workaround.
• Medium: A non-critical feature is not working correctly, or a small group of users is affected.
• Low: Minor issue, cosmetic bug, content correction, or general question.

For each severity level, agree on:

• Response time: How quickly the support team acknowledges the issue.
• Update frequency: How often your team will receive progress updates.
• Target resolution approach: Whether the aim is a quick workaround, full fix, or planned release.
• Communication channel: WhatsApp, email, ticketing system, phone call, or a combination.

It is important to distinguish response time from resolution time. Response time means the issue has been received, understood, and assigned. Resolution time depends on the cause, complexity, testing required, and whether third parties are involved. A trustworthy SLA avoids unrealistic promises and focuses on clear handling, ownership, and communication.

3. Clarify Backups, Recovery, and Data Responsibility

Backups are one of the most important SLA topics, but they are often discussed too late. A backup plan should answer two simple business questions: how much data could we afford to lose, and how quickly do we need the system restored?

Your SLA should define:

• What is backed up: database, uploaded files, system configuration, code, reports, or all of these.
• Backup frequency: daily, more frequent, or based on system criticality.
• Backup location: same hosting environment, separate storage, or another agreed location.
• Retention period: how long backups are kept.
• Restore responsibility: who performs the restore and who approves it.
• Restore testing: whether backups are tested periodically to confirm they can actually be used.

A backup is only useful if it can be restored. Businesses should not assume that because a hosting provider offers backups, the complete application can be recovered quickly in the exact state needed. Custom systems may include databases, files, environment settings, and integrations. All of these should be considered.

Also clarify data ownership. Your business should know where its data is stored, who can access it, and how access is controlled. If the system handles sensitive customer, financial, HR, or operational data, this discussion becomes even more important.

4. Set Rules for Maintenance, Monitoring, and Security Updates

After launch, every system needs care. Servers require updates, frameworks may need patches, certificates expire, integrations change, and performance can shift as usage grows. The SLA should explain what ongoing maintenance includes and what requires a separate request.

Start with maintenance windows. These are planned times when updates can be applied with minimal disruption. For Saudi and Gulf businesses, this may need to consider working hours, weekends, Ramadan schedules, campaign periods, peak sales days, or internal reporting cycles.

Your SLA should cover:

• Planned maintenance timing and notice period.
• Emergency maintenance handling.
• Server, framework, plugin, or library updates.
• SSL certificate monitoring and renewal responsibility.
• Performance monitoring and alerting.
• Error logging and review.
• Basic security patching scope.

Monitoring is another area where assumptions cause problems. If a system fails at midnight, who receives the alert? Is there automated monitoring, or does someone only notice when a user complains? If monitoring is included, define what is monitored: uptime, server resources, application errors, database performance, queue failures, or integration errors.

Security updates should also be clear. An SLA should not simply say “security included” without limits. It should explain whether the support team handles routine patching, dependency updates, vulnerability review, access management support, or emergency fixes. For highly sensitive systems, you may also need separate security testing, audit logs, or compliance review.

5. Create a Simple Change Request and Escalation Process

Once users start using a system, new ideas appear quickly. A department may request a new report, a manager may want a new approval flow, or customers may ask for a simpler form. These are normal and healthy signs that the system is becoming useful.

However, change requests should not be mixed with bug fixes. A bug means the agreed feature is not working as intended. A change request means adding, removing, or modifying functionality beyond the agreed scope.

Your SLA should define how change requests are submitted, estimated, approved, scheduled, tested, and released. This protects your budget and helps your team prioritize.

A practical change process includes:

• One official channel for requests.
• A short description of the business need, not only the feature idea.
• Impact assessment on timeline, cost, users, and integrations.
• Written approval before work starts.
• Testing and acceptance before release.
• Release notes so users know what changed.

Escalation paths are equally important. If an urgent issue is not progressing, who should be contacted next? Your SLA should list the operational contact, project or account contact, technical escalation contact, and business decision-maker on your side. This avoids delays when a quick decision is needed.

For larger organizations, it also helps to define who is allowed to approve urgent fixes, downtime, data restoration, or paid changes. Without this, technical teams can lose valuable time waiting for confirmation.

A Practical SLA Checklist Before Go-Live

Before you launch your custom system, review these points with your technology partner:

• What systems, modules, integrations, and environments are covered?
• What are the agreed support hours and communication channels?
• How are incidents classified by severity?
• What are the response expectations for each severity level?
• Who monitors uptime, errors, and performance?
• What backup schedule is in place, and how is restoration handled?
• When can planned maintenance happen, and how much notice is required?
• Who is responsible for security patches, certificates, and hosting updates?
• How are change requests submitted, estimated, approved, and released?
• Who are the escalation contacts on both sides?

Key Takeaways

• An SLA is not only a legal document; it is an operating agreement for life after launch.
• Define uptime, support hours, severity levels, backups, maintenance, and change requests before the system becomes business-critical.
• Separate bugs from new feature requests to avoid confusion and budget disputes.
• Make responsibilities clear for hosting, third-party services, monitoring, and data recovery.
• A good SLA improves communication during incidents and reduces operational risk.

If you are preparing to launch a website, portal, dashboard, or internal web app, Pioneers.dev can help you review the technical support model before go-live. You are welcome to request a free WhatsApp consultation to discuss what your SLA should include for your business context.