Si vas a incorporar una red de proxies a un pipeline de producción, alguien de compras o de ingeniería de plataforma acabará preguntando cuál es el SLA. Es la pregunta correcta, y las respuestas que obtengas suelen ser menos informativas de lo que parecen, porque una cifra como 99,9% no significa nada hasta que sabes contra qué se mide, durante qué periodo y qué ocurre cuando no se cumple.
También existe una trampa concreta en esta categoría. Un SLA de proxies promete que la puerta de enlace es accesible. No promete que los sitios de los que recopilas datos vayan a dejar pasar tus solicitudes, y son cosas muy distintas. Entender ese límite es la mayor parte de lo que necesitas saber antes de firmar nada.
Qué significa realmente una cifra de disponibilidad
Detrás de cada porcentaje hay tres variables, y un proveedor que solo te da el porcentaje te ha dado la parte menos útil.
La primera es la ventana de medición. Un SLA del 99,9% mensual permite aproximadamente 43 minutos de caída al mes. El mismo 99,9% medido anualmente permite unas 8 horas 45 minutos, y permite que esas horas sean consecutivas. Lo mensual es significativamente más estricto, y un proveedor que cita una cifra anual está ofreciendo una promesa más débil con el mismo lenguaje.
La segunda es la definición de caída del servicio. ¿Se considera que el servicio está caído cuando la puerta de enlace rechaza conexiones, o también cuando responde técnicamente pero la tasa de errores se ha disparado, o la latencia se ha degradado hasta el punto de ser inútil? Muchos SLA solo cuentan la indisponibilidad total, lo que significa que un periodo en el que todas las solicitudes devuelven un error pero el endpoint sigue aceptando conexiones puede no registrarse como caída en absoluto.
La tercera es quién lo mide. Si el proveedor es la única fuente de verdad y no publica ningún registro independiente, la cifra es autodeclarada. Una página de estado pública con historial de incidentes es lo que hace que la cifra se pueda verificar.
La distinción más importante: la disponibilidad de la puerta de enlace no es la tasa de éxito
Esta es la parte que sorprende a los equipos, y merece la pena decirlo sin rodeos.
Un SLA de disponibilidad cubre la infraestructura del proveedor: la puerta de enlace acepta tu conexión, te autentica y enruta tu solicitud. Eso es lo que controlan y eso es lo que prometen.
Lo que no cubre es si el sitio de destino acepta la solicitud. Si un sitio bloquea la dirección de salida, sirve una página de desafío o devuelve un resultado vacío, eso no es una caída. El proxy hizo su trabajo. Tu recopilación falló de todas formas. Ningún proveedor de proxies puede prometer una tasa de éxito frente a sitios de terceros, porque son los sitios los que deciden, cambian sus defensas sin previo aviso, y el mismo pool que funciona bien contra un objetivo el lunes puede tener dificultades el viernes. Cualquier proveedor que sí garantice una tasa de éxito sobre objetivos arbitrarios está prometiendo algo que está fuera de su control.
Así que la consecuencia práctica para compras es que el SLA te protege frente a que el proveedor falle, y tu propia monitorización te protege frente a todo lo demás. Necesitas ambas cosas, y confundirlas lleva a equipos que están cubiertos contractualmente pero ciegos a nivel operativo. Para eso sirve monitorizar tu pipeline, midiendo la tasa de éxito validada por objetivo y por región en lugar de asumir que el SLA lo cubre, y por eso importa detectar contenido bloqueado o falso: una página de desafío devuelta con un 200 es una respuesta conforme al SLA y un fallo de datos al mismo tiempo.
Los créditos de servicio, y lo que realmente valen
Cuando no se cumple un SLA, el remedio habitual es un crédito de servicio, normalmente un porcentaje de la cuota mensual escalado según lo grave que haya sido el incumplimiento del objetivo, aplicado a una factura futura.
Hay que ser realista sobre su magnitud. Un crédito se calcula sobre lo que le pagaste al proveedor, no sobre lo que te costó la interrupción. Si una caída de la puerta de enlace de cuatro horas paraliza un feed de precios que impulsa tus propias decisiones comerciales, el crédito será una pequeña fracción de una factura mensual de proxies y el impacto en el negocio es tuyo. Los créditos son un mecanismo de responsabilidad y una señal de que el proveedor se toma en serio el compromiso; no son un seguro.
Merece la pena revisar dos detalles mecánicos. Los créditos no suelen ser automáticos: muchos contratos exigen que los reclames dentro de un plazo, a menudo 30 días, con tus propias pruebas. Y los créditos suelen tener un tope de algún porcentaje de la cuota mensual. Ambas cosas son normales, pero conviene conocerlas antes de necesitarlas.
Las exclusiones que hay que leer con atención
La sección de exclusiones es donde realmente se define un SLA. Las estándar y razonables incluyen el mantenimiento programado anunciado con antelación, la fuerza mayor y los fallos en redes que el proveedor no opera. Presta atención a estas:
Mantenimiento programado sin límite ni periodo de aviso, lo que en la práctica permite al proveedor excluir cualquier caída que declare con antelación. Exclusiones por “mala configuración del cliente” que son lo bastante amplias como para cubrir un uso ordinario. Exclusiones de terceros redactadas de forma tan amplia que los problemas de red ascendentes, que son la mayor parte de lo que realmente falla, quedan fuera de la promesa. Y exclusiones por degradación como algo distinto de la indisponibilidad, que es como un servicio lento pero vivo evita ser contabilizado.
Comprueba también si el SLA cubre los componentes de los que realmente dependes. Un negocio de proxies tiene varios: la puerta de enlace, el panel y la autenticación, la facturación, y cualquier API. Un SLA que cubre la puerta de enlace mientras excluye la autenticación no ofrece mucha protección, ya que no puedes usar una puerta de enlace accesible contra la que no puedes autenticarte.
Cómo verificar una afirmación antes de firmar
Un SLA es una promesa sobre el futuro; lo que se puede verificar es el presente y el pasado.
Empieza por la página de estado. El estado en tiempo real y, más importante aún, un historial público de incidentes te dicen con qué frecuencia fallan las cosas, con qué rapidez se reconocen y si los análisis posteriores son honestos. Un proveedor sin página de estado pública te está pidiendo que confíes en la disponibilidad sin más. Shifter publica una en status.shifter.io con la puerta de enlace, las IP de ISP, las API, el panel y la autenticación, y la facturación seguidos como subservicios independientes, que es el nivel de detalle que interesa, ya que permite ver qué componente falló.
Después mídelo tú mismo durante la evaluación. Ejecuta una comprobación de disponibilidad de baja frecuencia contra la puerta de enlace desde tu propia infraestructura durante un periodo de prueba, y tendrás un registro independiente en lugar de una cifra de marketing. Combina eso con una prueba adecuada de tasa de éxito sobre tus objetivos reales, como en probar velocidad, tasa de éxito y precisión de ubicación, y conocerás ambas cifras: si el servicio está disponible y si funciona para ti.
Por último, fíjate en los tiempos de respuesta del soporte, porque en la práctica importan más que el crédito. Cuando algo se rompe a las 02:00, lo que determina tu recuperación es la rapidez con la que responde una persona, no el porcentaje que aparecerá en la factura del mes siguiente.
Lo que publica Shifter
A modo de referencia, los niveles publicados son: mejor esfuerzo en Starter hasta Growth, normalmente 99,5% o mejor; 99,9% de disponibilidad mensual en Business hasta Pro sin un mecanismo formal de crédito; y 99,9% en Enterprise con créditos de servicio según el contrato firmado, calculados sobre el gasto mensual y abonados como crédito en cuenta en la siguiente factura. Los tiempos de respuesta de soporte están escalonados en paralelo, desde chat de mejor esfuerzo en los planes de entrada hasta un canal dedicado y un gestor de cuenta asignado en Enterprise. Los detalles están en la documentación de soporte y SLA.
El motivo de decirlo con claridad es que la segmentación por niveles es normal en este sector y merece la pena entenderla: un SLA formal respaldado por créditos suele ser una característica de contrato empresarial, y si tu proceso de compras requiere uno, esa es la conversación que hay que tener por adelantado en lugar de asumir que un plan de autoservicio lo incluye.
Las preguntas que hacer en el proceso de compra
Pregunta por la ventana de medición y si es mensual o anual. Pregunta por la definición de caída, en concreto si cuentan las tasas de error elevadas o la latencia degradada. Pregunta qué componentes cubre el SLA, puerta de enlace, autenticación, panel, API, y si se miden por separado. Pregunta si los créditos son automáticos o si hay que reclamarlos, cuál es el plazo de reclamación y cuál es el tope. Pide el historial de incidentes de los últimos doce meses. Pregunta cuál es el compromiso de tiempo de respuesta de soporte para un incidente de producción caída, y por qué canal. Y pregunta qué queda excluido explícitamente.
Un proveedor cómodo respondiendo por escrito a todo eso te está diciendo algo útil, independientemente de la cifra en sí.
La conclusión
Trata el porcentaje como la parte menos informativa de un SLA. La ventana, la definición de caída, los componentes cubiertos y las exclusiones son lo que determina si la promesa significa algo, y los créditos de servicio son responsabilidad, no compensación por tus pérdidas. Y lo más importante, recuerda el límite: un SLA de disponibilidad cubre que la puerta de enlace esté disponible, nunca si los objetivos de terceros aceptan tu tráfico, así que sigues necesitando tu propia monitorización de tasa de éxito para saber si tu recopilación realmente funciona. Verifica con un historial público de incidentes y tus propias mediciones durante una prueba, y valora la capacidad de respuesta del soporte al menos tanto como la cifra en sí.
Si estás evaluando bajo esa base, las decisiones a nivel de plan se tratan en cómo elegir el plan de proxies residenciales adecuado, y los criterios a nivel de proveedor en cómo elegir una red de proxies. El servicio en sí son los proxies residenciales, con niveles y precios por GB que escalan desde autoservicio hasta condiciones de Enterprise contratadas.