1. Alcance
Este Acuerdo de Nivel de Servicio ("SLA") se incorpora por referencia a los Términos de Servicio y rige los compromisos de nivel de servicio que hacemos a los clientes que utilizan los Servicios descritos a continuación.
1.1 Servicios cubiertos
Este SLA se aplica a las siguientes categorías de Servicios:
- Servidores privados virtuales (VPS), incluidos todos los niveles KVM de Linux
- Servidores de Protocolo de Escritorio Remoto (RDP)
- Servidores dedicados (DS)
- Servidores GPU (GPU)
- Servidores de almacenamiento y copia de seguridad
- Servidores de streaming
- Servidores de juegos
1.2 Servicios con compromisos ajustados
El alojamiento compartido y cPanel tienen los compromisos de tiempo de actividad de la Sección 2, pero con la medición ajustada para la arquitectura de nivel compartido (el objetivo de medición relevante es la disponibilidad del host compartido en lugar de la disponibilidad del contenedor por cliente).
1.3 Servicios no cubiertos
El alojamiento de correo electrónico y SMTP tiene compromisos de disponibilidad separados publicados en sus respectivas páginas de producto. Los Servicios beta y de vista previa etiquetados explícitamente como tales no están cubiertos por este SLA.
2. Compromiso de tiempo de actividad
2.1 Planes estándar
Los planes estándar — VPS-1 a VPS-8, RDP-Basic y RDP-Pro, todos los niveles de Storage, Game-S y Game-M, Streaming-1 — tienen un compromiso de tiempo de actividad mensual del 99,9%.
Un tiempo de actividad mensual del 99,9% corresponde a un máximo de 43 minutos y 50 segundos de inactividad en un mes calendario de 30 días, o 44 minutos y 38 segundos en un mes de 31 días.
2.2 Planes Pro, Premium, Dedicados y GPU
Los planes de nivel superior — VPS-16, RDP-Power, todos los niveles Dedicados (DS-Lite a DS-Beast), todos los niveles GPU (GPU-Lite a GPU-Beast), Game-L, Streaming-2 — tienen un compromiso de tiempo de actividad mensual del 99,99%.
Un tiempo de actividad mensual del 99,99% corresponde a un máximo de 4 minutos y 23 segundos de inactividad en un mes calendario de 30 días, o 4 minutos y 28 segundos en un mes de 31 días.
3. Metodología de medición
3.1 Monitoreo externo
El tiempo de actividad se mide mediante nodos de monitoreo externos operados por proveedores de tiempo de actividad de terceros (UptimeRobot, Better Uptime o equivalente). Actualmente mantenemos tres (3) nodos de monitoreo independientes ubicados en regiones geográficamente distintas para evitar mediciones de punto único de falla.
3.2 Intervalo de sondeo
Cada nodo de monitoreo sondea el endpoint principal de cada Servicio cada cinco (5) minutos.
3.3 Detección por regla de mayoría
La inactividad se registra cuando al menos dos de los tres nodos de monitoreo informan que el Servicio no está disponible en la misma ventana de sondeo. Esto evita atribuir cortes de red locales en el nodo de monitoreo a un incidente de MurmurHost.
3.4 Acumulación de inactividad
Un "minuto de inactividad" es cualquier minuto completo durante el cual la detección por regla de mayoría está en estado no disponible. Los minutos parciales se redondean a minutos completos para fines de cálculo de créditos.
3.5 Medición del lado del cliente
Los clientes pueden usar su propia infraestructura de monitoreo para corroborar las reclamaciones de inactividad. Cuando la medición del lado del cliente diverge materialmente de nuestro monitoreo, compartiremos nuestros datos de medición y trabajaremos para acordar el período de inactividad real.
4. Créditos de servicio
4.1 Niveles de crédito
Si un Servicio cubierto cae por debajo de su compromiso de tiempo de actividad mensual, el cliente tiene derecho a un crédito de servicio calculado como un porcentaje de la tarifa mensual del Servicio afectado:
| Tiempo de actividad mensual | Crédito |
|---|---|
| Por debajo del 99,9% (o 99,99% para niveles superiores) pero ≥ 99,0% | 10% |
| Por debajo del 99,0% pero ≥ 95,0% | 25% |
| Por debajo del 95,0% pero ≥ 90,0% | 50% |
| Por debajo del 90,0% | 100% |
4.2 Aplicación
Los créditos de servicio se aplican a la siguiente factura del Servicio afectado. Si el cliente cancela el Servicio afectado antes de la siguiente factura, el crédito se paga como reembolso en el método de pago original, sujeto a los términos de procesamiento en la Política de Reembolso.
4.3 Límite
El crédito total para cualquier Servicio afectado en un solo mes no puede exceder el 100% de la tarifa mensual de ese Servicio. Los créditos de servicio son el recurso único y exclusivo del cliente por cualquier incumplimiento de los compromisos de tiempo de actividad bajo este SLA.
5. Exclusiones
Lo siguiente no cuenta como inactividad para los fines de la Sección 2:
5.1 Mantenimiento planificado
Mantenimiento anunciado con al menos cuarenta y ocho (48) horas de anticipación a través del panel del cliente y la página de estado en /status. Las ventanas de mantenimiento rutinarias se programan típicamente durante horas de baja demanda para la jurisdicción relevante.
5.2 Fuerza mayor
Actos de Dios, desastres naturales, guerra, disturbios civiles, acción gubernamental, terrorismo o eventos comparables fuera de nuestro control razonable.
5.3 Culpa del cliente
Inactividad causada por mala configuración del cliente, errores de software controlados por el cliente, exceder las asignaciones de recursos del plan u operaciones realizadas por el cliente (como reinicio voluntario, reinstalación del sistema operativo o cambio de configuración que deshabilite el acceso remoto).
5.4 Cortes de red de terceros
Inactividad causada por cortes de red de terceros fuera de nuestra red y fuera de nuestros acuerdos de interconexión, incluidos cortes del propio ISP del cliente, proveedor de tránsito o red de última milla.
5.5 Acción relacionada con la AUP
La suspensión bajo la AUP no cuenta como inactividad. Las suspensiones disputadas de la AUP revertidas en apelación no se cuentan retroactivamente como inactividad; el recurso del cliente en ese caso se documenta en la AUP.
6. Rendimiento de red
6.1 Objetivos de latencia
Nos comprometemos a objetivos de latencia mediana entre nuestra red perimetral y los principales intercambios de Internet regionales, medidos mensualmente:
| Región (origen) | Mediana objetivo al IX más cercano |
|---|---|
| Islandia (RVK) | < 5 ms a LIX |
| Suiza (ZRH) | < 2 ms a SwissIX |
| Países Bajos (AMS) | < 1 ms a AMS-IX |
| Rumania (BUC) | < 2 ms a InterLAN |
| Moldavia (KIV) | < 5 ms a MD-IX |
| Bulgaria (SOF) | < 3 ms a BIX.BG |
| Rusia (MSK) | < 3 ms a MSK-IX |
| Panamá (PTY) | < 4 ms a PA-IX |
6.2 Pérdida de paquetes
Nos comprometemos a menos del 0,1% de pérdida de paquetes en el tráfico intracentro de datos medido en cualquier ventana móvil de 5 minutos, excluyendo intervalos afectados por el filtrado activo de DDoS.
6.3 Rendimiento
Nos comprometemos a un rendimiento a la velocidad del puerto configurada en el Servicio, menos la sobrecarga típica de encapsulación y tránsito. El rendimiento sostenido materialmente por debajo de la velocidad del puerto (después de excluir la congestión de tránsito fuera de nuestra red) se trata como una falla de rendimiento de red.
7. Tiempo de mitigación de DDoS
7.1 Ataques volumétricos
Los ataques DDoS volumétricos dirigidos a los Servicios del cliente son detectados y etiquetados por nuestro borde de filtrado anycast dentro de los sesenta (60) segundos desde el inicio del ataque. La mitigación es automática y no requiere acción del cliente.
7.2 Ataques a nivel de aplicación
Los ataques a nivel de aplicación (L7) requieren reglas específicas de la aplicación. Proporcionamos reglas estándar en el borde para patrones comunes; las reglas adaptadas a la aplicación específica del cliente (rutas de URL, firmas de solicitud) son responsabilidad del cliente, opcionalmente configurables a través de Cloudflare o BunnyCDN en el borde de la aplicación.
7.3 Capacidad por nivel de plan
La capacidad de filtrado volumétrico escala con el nivel del plan y se documenta en /features/ddos-protection. Los ataques sostenidos por encima de la capacidad de filtrado del plan pueden desencadenar una conversación sobre actualización en lugar de un crédito de servicio.
8. SLA de aprovisionamiento
8.1 Servicios basados en KVM
Los planes KVM VPS, RDP, compartidos y cPanel completan el aprovisionamiento dentro de los cinco (5) minutos posteriores a la confirmación del pago. La confirmación es el momento en que el pago en criptomoneda alcanza las confirmaciones de umbral descritas en la página de métodos de pago; para pagos con tarjeta donde se admiten, la confirmación es el liquidación en el procesador.
8.2 Dedicados y GPU
Los planes dedicados y GPU de stock completan el aprovisionamiento dentro de las veinticuatro (24) horas posteriores a la confirmación del pago. Las construcciones dedicadas personalizadas (multi-GPU, configuraciones RAID exóticas, modelos de NIC específicos) se marcan al realizar el pedido y pueden tomar de 1 a 3 días hábiles.
8.3 Pedidos al por mayor
Los pedidos al por mayor (más de cinco Servicios en una sola transacción) requieren coordinación con el equipo de ventas. Los plazos de entrega se acuerdan al realizar el pedido y forman parte del SLA específico del pedido.
8.4 Créditos por falla de aprovisionamiento
Si el aprovisionamiento excede el objetivo relevante en más del 25%, el cliente tiene derecho a un crédito de servicio de un mes en el Servicio afectado. Esto se suma a cualquier crédito relacionado con el tiempo de actividad acumulado bajo la Sección 4.
9. Tiempos de respuesta de soporte
9.1 Definiciones de severidad
- Crítico: servidor caído, datos inaccesibles, incidente de seguridad en curso
- Alto: rendimiento degradado, interrupción parcial, inaccesibilidad intermitente
- Normal: pregunta de configuración, consulta de funciones, aclaración de facturación que no afecta la operación del servicio
- Bajo: comentarios sobre documentación, pregunta de proceso, solicitud no sensible al tiempo
9.2 Objetivos de respuesta
| Severidad | Primera respuesta | Actualización por hora | Objetivo de resolución |
|---|---|---|---|
| Crítico | 30 minutos | cada hora | mejor esfuerzo, página de estado actualizada |
| Alto | 2 horas | cada 4 horas | mejor esfuerzo dentro de 1 día hábil |
| Normal | 24 horas | según sea necesario | dentro de 3 días hábiles |
| Bajo | 48 horas | según sea necesario | dentro de 5 días hábiles |
9.3 Canales de soporte
Los tickets se aceptan a través del panel del cliente y por correo electrónico a [email protected]. El chat 24/7 (donde esté disponible, cargado de forma diferida según la documentación en /features) es para consultas generales; los problemas de severidad Crítico siempre deben abrirse también como tickets para garantizar el seguimiento.
10. Cómo reclamar créditos
10.1 Ventana de reclamación
Los créditos de servicio deben reclamarse dentro de los treinta (30) días posteriores al incidente que da lugar al crédito. Los créditos no reclamados dentro de esta ventana se pierden.
10.2 Procedimiento de reclamación
Para reclamar un crédito, envíe un correo electrónico a [email protected] con la siguiente información:
- Correo electrónico de la cuenta e identificador del Servicio afectado
- Fecha y hora del incidente en UTC
- Motivo de la reclamación (falla de tiempo de actividad, falla de aprovisionamiento, falla de rendimiento de red)
- Cualquier dato de monitoreo externo que el cliente tenga que corrobore el incidente
10.3 Procesamiento
Reconocemos las reclamaciones dentro de las cuarenta y ocho (48) horas. La resolución sustantiva generalmente se completa dentro de los siete (7) días hábiles. Los créditos aprobados se aplican a la siguiente factura o, a solicitud del cliente, se pagan como reembolso según la Sección 4.2.
11. Ventanas de mantenimiento
Los avisos de mantenimiento se publican en la página de estado en /status y se envían por correo electrónico a todos los clientes afectados. La ventana de aviso estándar es de cuarenta y ocho (48) horas. El mantenimiento de emergencia — requerido para abordar un problema activo de seguridad o estabilidad — puede realizarse sin aviso previo; en ese caso, se publica un análisis post-mortem en la página de estado dentro de los cinco (5) días hábiles.
12. Modificaciones a este SLA
Podemos actualizar este SLA periódicamente. Los cambios materiales que reduzcan el nivel de servicio garantizado bajo este SLA requieren un aviso de treinta (30) días a través del procedimiento en la Sección 15 de los Términos de Servicio. Los cambios que mejoren los compromisos o aclaren el lenguaje entran en vigencia inmediatamente después de su publicación. La fecha de "Última actualización" en la parte superior de este documento refleja el cambio más reciente.