Service Level Agreement | SYS24

Document version: 87 · Prepared 20 October 2026. This general Service Level Agreement explains how SYS24 operates and supports ordered services. It supplements the accepted order and Terms of service. Specific service hours, response targets, availability commitments, backup schedules and credits must be stated in your accepted plan or service schedule. This page does not invent a numerical uptime guarantee, unlimited support or round-the-clock coverage for every product.

1. Covered services and service boundaries

Your order identifies the subscription, workspace, domain, hosting package, infrastructure, supported users or devices, project or maintenance tasks covered. SaaS support concerns the contracted platform and enabled modules; hosting support concerns the agreed hosting boundary; managed IT support concerns the listed environment. Custom development, training, data repair, migrations, on-site attendance and third-party administration are included only where agreed. We will explain when a request needs a quotation or another support provider before undertaking additional chargeable work.

2. Support channels, hours and authority

Use the client portal Help or support channel shown on your order or invoice. Include the affected service, workspace, start time, impact, steps to reproduce and a safe screenshot or error reference. Never send passwords, complete payment-card data or unnecessary identity documents in an ordinary ticket. A social-media message or reply to an unmonitored automated address is not a reliable incident channel.

Coverage hours, time zone, after-hours arrangements and emergency contacts are those in the service schedule. If they are not specified, request written confirmation before relying on a particular coverage window. Ticket creation can be available outside staffed hours without implying immediate attendance. Only authorised contacts can approve sensitive account changes, paid work or restoration. We may verify identity and require a designated decision-maker.

3. Incident priorities

• Critical: a confirmed complete outage of the contracted production service or a serious active security incident with no reasonable workaround. We assess containment, impact and provider escalation urgently within the purchased coverage.
• High: major loss of a core function affecting multiple users or important operations, with limited workarounds.
• Normal: a partial fault, an individual-user issue, degraded non-critical functionality or a problem with a practical workaround.
• Service request: advice, access changes, reports, training, feature requests or planned configuration work.

We may revise a priority after assessment and explain why. The order sets any binding numerical acknowledgement or response target. A response means a meaningful acknowledgement and initial assessment, not necessarily resolution. Resolution depends on diagnosis, access, complexity, third-party action and agreed change windows. Any target clock follows the contracted coverage and documented rules for waiting on information or approval; we will not use avoidable delays to defeat a committed target.

4. Incident handling and communication

We record requests, assess scope and severity, investigate, propose a workaround or fix, and escalate to the relevant technical team or supplier. We will communicate material findings and next steps through the ticket or agreed incident channel, including when action is needed from you. For material incidents, updates and any post-incident report follow the service schedule and reasonable circumstances. A request is closed when resolved, accepted or otherwise handled under the agreed closure process; you may report a recurrence with the original reference.

5. Availability and performance

Only an expressly stated service-specific availability target is binding as a numerical commitment. Its schedule must identify the measured component, monitoring source, reporting period, time zone and permitted exclusions. Where agreed, availability is calculated as eligible service minutes less qualifying unavailability, divided by eligible service minutes. A client device, local connection or uncontracted third-party application failing does not by itself establish an outage of the contracted platform. We will consider customer evidence when monitoring differs.

Performance depends on package resources, traffic, data size, integrations, client networks and supported software. Resource or fair-use limits must be disclosed in the plan. We will investigate repeatable material degradation and explain options. “Unlimited” marketing does not authorise abusive or unlawful resource use and must be interpreted fairly with disclosed plan conditions.

6. Maintenance and changes

We may perform maintenance, security updates, capacity work and compatibility changes. Planned disruptive work will be communicated in advance where reasonably practicable, using the notice and window agreed in your schedule. Emergency security work may need immediate action followed by an explanation. We seek to reduce impact and use appropriate rollback or recovery planning.

Recurring IT maintenance is scheduled as ordered. Coming-soon or due notices are reminders; they do not mean checks have been completed or an invoice paid. Completion and findings are recorded separately. Customer-specific changes require authorised approval, suitable backups and a safe window where applicable. Customer modifications to managed components can affect support scope, but do not automatically remove unrelated statutory rights or our obligations.

7. Third-party dependencies

Registries, registrars, DirectAdmin servers, connectivity suppliers, banks, PayFast, Whop, Paystack, SMS providers, VerifyNow and other enabled API vendors can affect completion and timing. We will escalate supplier incidents within our reasonable control and explain material dependencies. Payment returns do not settle invoices until verified reconciliation. SMS acceptance does not guarantee handset delivery; verification responses depend on the source and method. A provider incident is assessed against the actual service schedule and law, rather than automatically excluded in every circumstance.

8. Backups, retention and disaster recovery

The order must define included backup scope, frequency, retention, storage separation, encryption responsibilities and any restore testing or charges. Recovery Point Objective means the agreed acceptable data-loss window; Recovery Time Objective means the agreed target restoration time. Neither is guaranteed merely because backups exist. In the absence of a written commitment, request clarification and maintain appropriate independent copies.

Restoration requires identifying a suitable backup, validating authority and assessing integrity, compatibility and impact on newer data. We will explain known risks before an overwrite where practicable. Failed updates may retain private recovery files and maintenance mode to protect consistency. Do not delete recovery records or force an interrupted migration back online without assessment. Domain expiry, released resources, corrupted source data or provider deletion can make complete recovery impossible; legal duties and agreed remedies still apply.

9. Security and data incidents

We use safeguards appropriate to the service and information risks, including access controls and supported security processes. Customers must maintain authorised users, endpoints, credentials, lawful data collection and timely reporting. No service can promise freedom from every attack. Suspected incidents are assessed and contained, evidence is preserved as appropriate and notification duties are handled under applicable law and the operator agreement. Do not independently test or attack shared infrastructure without written permission.

10. Customer cooperation and service interruptions

Provide accurate information, supported equipment or software, lawful access and timely approvals. Tell us about critical dates and dependencies before relying on a service for them. Delays caused by missing required information will be documented and handled under the agreed clock rules. Billing suspension and termination are governed by the Terms and order. Where a lawful, disclosed reinstatement fee applies, it will be itemised and notified; settlement does not guarantee recovery of permanently deleted resources. Unjustified suspension or service defects remain open to complaint and remedy.

11. Credits, complaints and remedies

Service credits apply only where expressly included in the service schedule, which must state the calculation, eligibility, evidence, claim process and claim period. No automatic percentage credit or claim deadline is created by this general page. Submit a service-level complaint through Help with incident references, impact and relevant monitoring evidence. We will investigate fairly and explain the outcome. A contractual credit is not an exclusive remedy where mandatory law provides other rights; valid claims are not rejected merely because a service was supplied online.

12. Review and contact

Review coverage when adding workspaces, modules, users, sites, infrastructure or business-critical workflows. Changes to committed targets require the applicable agreement and notice, not a silent website edit. For a copy of your service schedule or clarification, use Help or contact@sys24.tech. Read this SLA with the Terms of service and Privacy Notice.