Effective Date: [16/04/2026]
Last Updated: [16/04/2026]
This Service Level Agreement (“SLA”) describes the performance targets that RedSwitches Pte Ltd. applies to its bare-metal cloud infrastructure services. By using RedSwitches services, you (“Client”, “you”) acknowledge and agree to the terms set out in this SLA. This SLA is incorporated by reference into the RedSwitches Terms of Service.
1.1 This SLA applies to bare-metal dedicated server services, network connectivity, and power infrastructure provided by RedSwitches Pte Ltd. (“RedSwitches”, “we”, “us”) to its clients.
1.2 RedSwitches is a bare-metal cloud infrastructure provider. We supply dedicated physical hardware, power, and network connectivity. We monitor our network and hardware continuously. We do not access, monitor, or control the operating system, applications, or any content that clients run on their servers, except where a Client has separately requested and RedSwitches has accepted OS monitoring as a complementary managed service.
1.3 This SLA covers network availability and power uptime at the infrastructure layer. It does not cover the performance of client operating systems, applications, databases, or software running on provisioned hardware, unless OS monitoring has been specifically requested and accepted in writing by RedSwitches.
1.4 This SLA should be read together with the RedSwitches Terms of Service and any applicable Order Form or Master Service Agreement.
For the purposes of this SLA:
“Uptime” means the percentage of time within a calendar month during which the RedSwitches Network and Power Infrastructure are available and operational at the network port level, calculated as:
Uptime % = ((Total Minutes in Month − Downtime Minutes) ÷ Total Minutes in Month) × 100
“Downtime” means a period during which the Client’s dedicated server is unreachable due to a failure within RedSwitches’ Network or Power Infrastructure, as measured at the network port level. Downtime excludes all periods described in Section 6 (Exclusions) and does not include unavailability caused by client-side factors, including but not limited to OS crashes, application failures, misconfigurations, or security incidents originating within the client environment.
“Scheduled Maintenance” means planned maintenance activities on RedSwitches infrastructure that are communicated to Clients in advance via email or the RedSwitches status page, in accordance with Section 7 of this SLA.
“Emergency Maintenance” means unplanned maintenance activities required to address urgent security vulnerabilities, prevent network instability, or protect the integrity of the infrastructure, which may be performed without advance notice.
“Network” means the physical and logical network infrastructure operated by RedSwitches, including switches, routers, uplinks, and peering connections, up to and including the physical port assigned to the Client’s server. It does not extend to the Client’s OS networking stack, applications, or any upstream or downstream networks beyond RedSwitches’ direct control.
“Service” means the bare-metal dedicated server, network connectivity, and power infrastructure provisioned to the Client by RedSwitches under an active service agreement.
“Hardware Failure” means a confirmed failure of a physical hardware component (e.g., disk, RAM, NIC, CPU, power supply unit) within the dedicated server provisioned to the Client, determined following RedSwitches’ diagnostic assessment.
“OS Monitoring” means the optional complementary managed service by which RedSwitches monitors the Client’s operating system at the Client’s request, subject to separate agreement.
3.1 RedSwitches targets 99.99% network and power uptime per calendar month across its infrastructure.
3.2 This target equates to a maximum of approximately 4.38 minutes of unplanned Downtime per calendar month.
3.3 This uptime commitment applies to:
3.4 This uptime commitment does not apply to:
3.5 Where the Client has separately requested and RedSwitches has accepted OS Monitoring as a complementary managed service, the scope of monitoring and any associated commitments will be set out in a separate written agreement.
4.1 Uptime is measured at the network port level — the physical interface between the Client’s server and RedSwitches’ network infrastructure.
4.2 RedSwitches uses continuous internal monitoring systems to track network and power availability across its data center infrastructure, 24 hours a day, 7 days a week, 365 days a year.
4.3 Availability determinations are based on RedSwitches’ internal monitoring records, which constitute the authoritative source for uptime calculations under this SLA.
4.4 Measurement scope — important clarification: Because RedSwitches does not have access to, and does not monitor, client operating systems or application layers (unless OS Monitoring has been separately agreed), Downtime is assessed solely at the infrastructure level. An unresponsive server due to an OS crash, kernel panic, failed application, or misconfiguration does not constitute Downtime for the purposes of this SLA.
4.5 Where the Client has opted in to OS Monitoring, RedSwitches’ monitoring scope expands accordingly, and any separately agreed OS-level availability commitments will supersede this section to the extent of any conflict.
5.1 This SLA is a best-effort performance target, not a contractual guarantee with financial remedies.
5.2 RedSwitches commits to making commercially reasonable efforts to achieve the 99.99% uptime target. However, failure to meet this target in any given calendar month does not entitle the Client to service credits, financial compensation, account credits, fee reductions, refunds, or any other monetary remedy.
5.3 No service credits. RedSwitches does not issue service credits for SLA misses. This is consistent with established industry practice among bare-metal infrastructure providers: Hetzner publishes no formal SLA for dedicated servers, and Leaseweb publishes no uptime percentage commitment for its infrastructure services.
5.4 The absence of financial remedies reflects the nature of bare-metal infrastructure provision, where the Client exercises full control over the server environment (OS, applications, configurations) and RedSwitches’ infrastructure-level responsibility is limited accordingly.
5.5 Clients seeking infrastructure with contractual uptime guarantees and associated financial remedies should evaluate managed cloud offerings or higher-tier managed service arrangements.
5.6 Nothing in this SLA limits RedSwitches’ obligations under the main Terms of Service or applicable law. This SLA does not affect any statutory rights the Client may have under applicable law.
The following events and periods are excluded from Downtime calculations and are not covered by the uptime target in Section 3:
6.1 Scheduled Maintenance
Periods of unavailability resulting from Scheduled Maintenance, provided that RedSwitches has given the Client reasonable prior notice via email or the RedSwitches status page, are excluded from Downtime. RedSwitches will endeavour to schedule maintenance during low-traffic periods and to minimise service disruption.
6.2 Client-Caused Issues
Unavailability caused by factors within the Client’s control, including but not limited to:
6.3 Force Majeure
Unavailability resulting from events beyond RedSwitches’ reasonable control, including but not limited to: natural disasters, earthquakes, floods, fires, pandemics, acts of war, terrorism, government orders, power grid failures, or other events of force majeure, as further defined in the RedSwitches Terms of Service.
6.4 DDoS Attacks
Unavailability caused by Distributed Denial of Service (DDoS) attacks, volumetric attacks, or other malicious network attacks directed at the Client’s server, IP addresses, or the surrounding network infrastructure. RedSwitches employs network-level DDoS mitigation on a best-effort basis; targeted attacks may affect availability despite these measures.
6.5 Upstream Provider Outages
Unavailability caused by failures of upstream network providers, internet exchange points, transit carriers, or peering partners beyond RedSwitches’ direct network infrastructure.
6.6 Emergency Maintenance
Periods of unavailability resulting from Emergency Maintenance performed to address security vulnerabilities, prevent network instability, protect infrastructure integrity, or comply with applicable legal obligations. Emergency Maintenance may occur without advance notice.
6.7 Client Suspension or Termination
Any period during which the Client’s service has been suspended or terminated by RedSwitches in accordance with the Terms of Service (e.g., for non-payment, acceptable use violations, or abuse).
6.8 Third-Party Services and Integrations
Failures or unavailability attributable to third-party services, APIs, or integrations not operated or controlled by RedSwitches.
7.1 Scheduled Maintenance: RedSwitches will provide reasonable prior notice of Scheduled Maintenance activities via email to the Client’s registered account address. Where practicable, at least 48 hours’ advance notice will be given for Scheduled Maintenance that is likely to cause service interruption.
7.2 Emergency Maintenance: Emergency Maintenance may be performed without advance notice where necessary to address urgent security vulnerabilities, prevent network or hardware instability, or take action required by applicable law or regulation. RedSwitches will communicate Emergency Maintenance activities through the status page as promptly as practicable.
7.3 Status Page: RedSwitches maintains a status page to communicate ongoing incidents, scheduled maintenance windows, and service updates. Clients are encouraged to subscribe to status page notifications.
7.4 RedSwitches will endeavour to minimise the duration and frequency of all maintenance activities and to perform disruptive maintenance during off-peak hours where feasible.
8.1 Upon confirmation of a Hardware Failure affecting a Client’s dedicated server, RedSwitches will use best efforts to replace or repair the failed hardware component within 4 hours of confirmed diagnosis.
8.2 The 4-hour target is a best-effort commitment only and is subject to:
8.3 For hardware failures requiring sourcing of parts not held in local inventory, replacement timelines may exceed 4 hours. RedSwitches will communicate expected timelines to affected Clients as promptly as practicable.
8.4 RedSwitches maintains spare hardware inventory at its primary data center locations. Availability of specific components cannot be guaranteed.
8.5 In cases where hardware replacement is not feasible within a reasonable timeframe, RedSwitches will work with the Client to identify alternative solutions, including migration to an equivalent server where available.
8.6 Where data recovery is relevant, Clients are responsible for maintaining their own backups. RedSwitches is not responsible for data loss resulting from hardware failures. See the Terms of Service for further detail on data liability.
9.1 RedSwitches monitors its network and hardware infrastructure 24 hours a day, 7 days a week. This continuous monitoring covers:
9.2 Network and hardware monitoring is performed by RedSwitches’ operations team and automated monitoring systems. This monitoring does not extend to client operating systems, applications, or data.
9.3 RedSwitches maintains a publicly accessible status page for communication of active incidents, maintenance windows, and service updates. The status page is available at the URL published on the RedSwitches website.
9.4 Clients experiencing service disruptions are encouraged to:
(a) Check the RedSwitches status page for active incidents or maintenance notices;
(b) Submit a support ticket through the RedSwitches customer portal; and
© Contact RedSwitches support for urgent infrastructure issues.
9.5 RedSwitches’ support team is available 24/7 for infrastructure-related incidents.
10.1 RedSwitches reserves the right to modify this SLA at any time. Notice of material changes will be provided via email to the Client’s registered account address or through the RedSwitches website, with at least 14 days’ advance notice before changes take effect.
10.2 Continued use of RedSwitches services after the effective date of any modification constitutes acceptance of the revised SLA.
10.3 If a Client objects to a material modification, they may terminate their service in accordance with the Terms of Service before the modification takes effect.
10.4 The most current version of this SLA will always be available on the RedSwitches website.
This SLA is governed by the laws of the Republic of Singapore and is subject to the dispute resolution provisions of the RedSwitches Terms of Service. For questions about this SLA, contact [email protected].