Qué ha cambiado en Lunixar desde la versión 1

Si tú usas un RMM en serio (ya sea como MSP o como TI interno), sabes que hay dos tipos de herramientas:

• Las que “más o menos jalan” pero te obligan a adaptarte tú a ellas.
• Y las que van madurando hasta que sientes que la plataforma trabaja contigo.

Desde que Lunixar entró a versión 1.0, el enfoque ha sido justo ese: menos fricción, más control, más trazabilidad y un sistema más sólido para operar a escala.

No te voy a soltar un changelog técnico con 80 líneas. Mejor: te explico los cambios que sí se sienten en operación, por qué importan y cómo aprovecharlos.

1) Alertas con más contexto (ya no es “sonó algo”, ahora sabes qué pasó)

Uno de los saltos más importantes desde 1.0 es que las alertas dejaron de ser solo “un registro”, y se volvieron un flujo con historia.

Ahora puedes ver:

• Estado de la alerta (activa/resuelta/ignorada),
• Primera y última detección,
• Ocurrencias,
• Fecha de resolución,
• Y un timeline/historial de eventos para entender el “cómo llegó a aquí”.

Esto parece detalle, pero cambia todo porque te evita el típico:

“¿Esto ya venía pasando o apenas empezó?”

Con trazabilidad real, tu soporte se vuelve más rápido, más profesional y menos reactivo.

Tip práctico: cuando un cliente diga “siempre falla”, abre el timeline y usa los datos como evidencia. Eso te ayuda a justificar acciones (y también a defenderte).

2) Menos ruido y más señal en notificaciones por correo

Si tú operas alertas en serio, sabes el problema: correo masivo = la gente deja de leerlo.

Desde la 1.x se reforzó la parte de notificaciones para que sea más operable:

• Configuración por empresa (no “cada quien a su bola”).
• Reglas por tipo de alerta y categoría.
• Destinatarios por regla (no una lista global confusa).
• Enfriamiento para evitar correos duplicados cuando hay varias instancias.
• Plantillas por idioma del usuario (ES/EN).

En otras palabras: más control para que las alertas se lean, no se ignoren.

Tip práctico: pon como destinatarios por default a pocas personas (owner + 1 responsable) y escala después. Si empiezas con “todos reciben todo”, te compras el problema del spam desde el día 1.

3) Reglas de alertas más flexibles (por tipo de dispositivo, como debe ser)

Esto es de los cambios más “MSP-friendly”: ahora las reglas pueden manejar múltiples tipos de dispositivo (y con comportamiento inteligente de “todos los tipos”).

¿Por qué importa?

Porque no es lo mismo:

• Una laptop de usuario que se apaga diario,
• Un servidor que debe estar 24/7,
• Una VM crítica,
• O un equipo “desconocido” que apenas estás inventariando.

Con filtros por tipo de dispositivo, puedes hacer reglas con sentido.

Tip práctico: para “DeviceDisconnected”, pon reglas estrictas para servidores y VMs… y reglas mucho más tolerantes (o apagadas) para laptops/desktop de usuarios.

4) Realtime de verdad (cuando pasa algo, lo ves)

En la 1.x se reforzó el flujo realtime:

• Sesiones realtime por empresa,
• Validación de sesión (bind + heartbeat),
• Eventos push cuando una alerta se dispara,
• Popups realtime en la UI,
• Y el badge de “no vistas” más consistente y menos dependiente de polling.

El resultado práctico: ves lo importante cuando ocurre, sin estar refrescando pantallas o “a ver si ya salió”.

Tip práctico: si tú usas NOC o monitoreo en vivo, el realtime es lo que te permite reaccionar antes de que el usuario levante ticket. Esa diferencia es la que vende el servicio.

5) Endurecimiento silencioso (lo que no se ve, pero te evita dolores)

Esta parte no es “sexy”, pero es la que define si una plataforma aguanta producción con clientes de verdad.

Desde 1.0 se fortalecieron varias cosas a nivel plataforma:

• Rate limiting en endpoints sensibles (para evitar abuso y picos),
• Mejor ordenamiento del lado del servidor en listados grandes (cuando ya hay volumen),
• Mejoras de compatibilidad y flujos retrocompatibles para no romper a usuarios,
• Y ajustes en el puente interno backend ↔ websocket para operación más estable.

¿Traducción? Menos sorpresas. Menos “hoy amaneció raro”. Más consistencia.

Tip práctico: cuando estés creciendo clientes, tu problema no es “tener más features”, es que lo que ya tienes se mantenga sólido. Estas mejoras son justo para eso.

6) UX: menos clicks, más claridad (sobre todo en móvil)

Algo que se pulió mucho fue la experiencia para administrar reglas y destinatarios:

• Settings mejor ordenado,
• Pantallas dedicadas (en vez de diálogos incómodos),
• Mejor jerarquía en sidebar,
• Filtros y búsquedas más limpias,
• Mejor compatibilidad móvil.

Esto parece menor… hasta que tienes que configurar 20 reglas y 10 usuarios, y agradeces que no sea una pelea.

Tip práctico: cada vez que simplificas configuración, reduces errores. Y eso baja tickets internos de “oye, no me llegan alertas” o “me llegan de todo”.

Bonus: qué te dice esto si estás evaluando Lunixar

Si tú estás viendo opciones de RMM, esta lista de cambios dice algo importante:

• Lunixar no solo está agregando cosas,
• está madurando lo que ya existe para que se use en operación real.

Para un MSP, eso vale más que un “feature nuevo” cada mes.

Cierre

Desde la versión 1.0, Lunixar se ha enfocado en tres cosas que realmente importan si tú operas TI todos los días:

• Alertas con trazabilidad real (menos adivinar),
• Notificaciones configurables y sin spam (más señal),
• Plataforma más sólida y realtime (menos fricción).

Si tú estás cansado de un RMM que se siente como “un montón de cosas pegadas”, Lunixar va justo por el camino contrario: hacerlo simple para el técnico, útil para la operación y estable para escalar.

Y si quieres ver por dónde van las próximas mejoras (alertas nuevas, seguridad, automatización y más), este tipo de actualizaciones seguirán siendo parte del rumbo: menos caos, más control.