Control de asistencia , Licencia
by 7 de septiembre de 2026

Qué hacer si un reloj checador queda sin conexión: continuidad y sincronización

Que un reloj checador aparezca “sin conexión” no significa automáticamente que se hayan perdido las asistencias. En muchos proyectos, el dispositivo y el software son dos capas distintas: el reloj puede continuar identificando empleados y guardando eventos localmente, mientras la plataforma deja de recibirlos hasta que se restablece la comunicación. En otros casos, una falla de energía, un cambio de IP, una red Wi-Fi inestable o una configuración incorrecta sí pueden interrumpir el registro.

La diferencia es importante. Si el equipo sigue registrando, la prioridad es preservar esos eventos y recuperar la sincronización de forma controlada. Si el equipo dejó de operar, la prioridad cambia a continuidad operativa: habilitar un método alterno, documentar la incidencia y evitar que recursos humanos “reconstruya” después la jornada sin evidencia suficiente.

Para empresas mexicanas, este tema cobra más relevancia en 2026. La reforma a la Ley Federal del Trabajo publicada el 1 de mayo de 2026 incorporó la obligación de registrar electrónicamente el inicio y la finalización de la jornada, cuyas disposiciones generales entrarán en vigor a partir del 1 de enero de 2027 conforme al ámbito y las excepciones que determine la STPS. Además, el artículo 804 de la LFT contempla los controles de asistencia entre los documentos que el patrón debe conservar cuando los lleva en el centro de trabajo (Diario Oficial de la Federación, 2026; Cámara de Diputados del H. Congreso de la Unión, 2026).

 

Idea clave

El objetivo no es “hacer que vuelva a aparecer en línea” lo más rápido posible a cualquier costo. Es conservar la continuidad del registro, proteger los eventos originales, restablecer la comunicación y demostrar que la sincronización posterior no creó huecos, duplicados o cambios de hora.

 

Primero: identifica qué significa “sin conexión” en tu caso

La frase “el checador está offline” puede describir problemas muy distintos. Antes de reiniciar, borrar o reconfigurar el dispositivo, identifica qué capa falló. Esta clasificación evita acciones que empeoran la incidencia.

 

 

Una caída de internet no es lo mismo que una pérdida de registros

Terminales de asistencia con memoria local almacenan eventos hasta un límite definido por el modelo. Por ejemplo, ZKTeco Tienda Oficial publica 100,000 eventos para M1 y Horus TL2, 150,000 para M2-LR y M2F PRO-LR, y 200,000 para SpeedFace-V3L. Esa capacidad no debe interpretarse como garantía de cuántos días puede permanecer una sede desconectada: depende de empleados, marcas por persona, eventos administrativos y comportamiento del firmware (ZKTeco Tienda Oficial, s. f.-a, s. f.-b, s. f.-c, s. f.-d, s. f.-e).

La memoria local funciona mejor como buffer de contingencia que como archivo histórico. Si una empresa deja un dispositivo desconectado durante semanas sin revisar su capacidad, puede acercarse al límite y aumentar el riesgo operativo. Por eso, la primera pregunta debe ser: “¿el reloj sigue aceptando y almacenando checadas?”; la segunda: “¿cuántos eventos pendientes existen y desde cuándo?”.

Qué NO hacer cuando el reloj pierde conexión

Durante una incidencia, algunas acciones parecen rápidas pero pueden destruir evidencia o complicar la recuperación. Antes de intervenir, evita cambios irreversibles.

  • No restablezcas el equipo a valores de fábrica como primera medida. Puedes borrar usuarios, plantillas, configuraciones y registros pendientes.
  • No elimines el dispositivo del software y lo vuelvas a crear sin documentar el identificador anterior. Podrías provocar duplicados o romper la asociación histórica.
  • No borres registros locales para “liberar memoria” antes de confirmar que ya fueron recibidos y respaldados.
  • No cambies manualmente fecha, hora o zona horaria sin registrar el motivo. Una corrección de reloj puede desplazar eventos o dificultar la conciliación.
  • No modifiques IDs de empleados durante la contingencia. El mismo colaborador debe conservar una identidad consistente en dispositivo, software y nómina.
  • No abras puertos indiscriminadamente ni desactives firewall o antivirus de forma permanente para probar conectividad. La recuperación no debe crear una exposición de seguridad.
  • No importes varias veces el mismo archivo o lote sin revisar cómo maneja duplicados el software.
  • No “rellenes” las marcas faltantes directamente en el reporte final sin conservar la evidencia de que fueron correcciones por contingencia.

 

Antes de tocar la configuración

Captura evidencia: fecha y hora del incidente, nombre de la sede, modelo, número o identificador del dispositivo, estado de red, última marca visible en el software, primera marca pendiente en el reloj y responsable que atiende. Ese pequeño registro simplifica la conciliación posterior.

 

Plan de continuidad: qué hacer mientras el checador está sin conexión

1. Confirma si el equipo sigue registrando localmente

Haz una prueba controlada con uno o dos usuarios autorizados y verifica en el propio dispositivo que el evento se haya generado. No basta con que el equipo muestre “verificación exitosa”: si el modelo permite consulta de autoservicio o registros locales, confirma que la marca está en la memoria. Horus TL2, por ejemplo, publica operación sin conexión y consulta de registros desde el equipo, además de una capacidad local de 100,000 eventos (ZKTeco Tienda Oficial, s. f.-a).

Si el equipo no registra, cambia inmediatamente al procedimiento alterno de asistencia definido por la empresa. Puede ser una lista controlada, un formulario interno, una app autorizada o una estación de respaldo. El método debe registrar como mínimo identidad, fecha, hora, tipo de evento y responsable del proceso. Después, las correcciones en el software deben quedar trazables.

 

 

2. Registra la ventana exacta de la falla

Anota la última marca recibida por el software y la primera marca que ya solo aparece en el reloj. Esa ventana permite saber qué periodo debe reconciliarse. En una empresa con varios dispositivos, no asumas que todos fallaron al mismo tiempo: un switch, un punto de acceso o una VLAN pueden afectar solo una parte de la sede.

3. Estima el backlog y el margen de almacenamiento

Calcula aproximadamente cuántos eventos se generan por día. Una plantilla de 100 personas que marca cuatro veces al día puede producir alrededor de 400 eventos diarios de asistencia, antes de considerar otros registros. La cifra sirve para estimar urgencia, no para agotar la memoria hasta su último registro. Si el reloj se acerca a su capacidad publicada, la prioridad debe ser recuperar comunicación o realizar una extracción segura y verificada.

4. Mantén estable la hora del dispositivo

La hora es parte de la evidencia. Si el reloj conserva correctamente fecha, zona horaria y minutos durante la caída, evita ajustarlo solo porque el software muestra retraso en la recepción. El evento puede haberse generado a las 08:01 y llegar al servidor dos horas después; esas dos horas no deben confundirse. En la conciliación conviene distinguir hora del evento, hora de recepción y, cuando exista, hora de modificación administrativa.

5. Comunica a recursos humanos que existe una incidencia de sincronización

Durante la caída, un dashboard puede mostrar personas “sin registro” aunque sí hayan marcado en el reloj. No conviene generar sanciones, descuentos o incidencias definitivas con información incompleta. Define un estatus temporal, por ejemplo “pendiente de sincronización”, hasta que se valide el lote recuperado.

Diagnóstico de red: qué revisar antes de culpar al software

Cuando el reloj sigue funcionando localmente, la recuperación suele comenzar en red. El objetivo no es cambiar parámetros al azar, sino seguir una secuencia que permita aislar el punto de falla.

 

 

TCP/IP: revisa la ruta completa

En un reloj con Ethernet, una IP visible no prueba que exista comunicación extremo a extremo. Verifica dirección, máscara, gateway, DNS cuando corresponda y el camino hacia el servidor. Si recientemente se cambió el router, switch, VLAN o rango DHCP, compara la configuración actual con la documentación de instalación. Para dispositivos fijos, una reservación DHCP o IP documentada puede reducir cambios inesperados, siempre que el diseño de red de la empresa lo permita.

Wi-Fi: la señal “conectado” tampoco es suficiente

Un checador puede mostrar el nombre de la red y aun así perder acceso por señal débil, cambio de contraseña, aislamiento de clientes, portal cautivo o políticas nuevas. M1 publica conectividad Wi-Fi de 2.4 GHz y Horus TL2 Wi-Fi de 2.4 GHz además de TCP/IP; si la sede sufre desconexiones recurrentes y el equipo admite cable, conviene evaluar si Ethernet ofrece una ruta más estable para una instalación fija (ZKTeco Tienda Oficial, s. f.-a, s. f.-b).

Nube y ADMS/PUSH: revisa salida, no abras internet sin criterio

En plataformas en la nube, algunos dispositivos compatibles utilizan comunicación push/ADMS para iniciar el envío de datos hacia un servicio remoto. Por eso no debe asumirse que la solución consiste en exponer el reloj directamente a internet o crear un reenvío de puertos. Los parámetros, destinos y reglas de salida dependen del modelo, firmware y plataforma. Utiliza la lista de compatibilidad, la documentación del fabricante y reglas mínimas de firewall. Si el dispositivo tenía comunicación y dejó de tenerla después de un cambio de red, documenta qué política cambió antes de modificar el reloj.

Cómo sincronizar después de recuperar la conexión

La reconexión no termina cuando el icono pasa de rojo a verde. El paso crítico es demostrar que el periodo desconectado llegó completo y que el software lo interpretó con los mismos usuarios, turnos y fechas.

  1. Conecta primero un dispositivo o una sede piloto. Evita restaurar todos los relojes simultáneamente si existe un backlog grande y la plataforma no ha sido probada.
  2. Confirma la fecha, hora y zona horaria del reloj antes de sincronizar. Si existe una diferencia importante, documenta el desfase y no corrijas masivamente la hora sin revisar qué eventos ya fueron generados. La hora del evento y la hora en que el servidor lo recibe son datos distintos.
  3. Espera a que el dispositivo termine de enviar los eventos pendientes. No borres memoria ni fuerces varias importaciones mientras la cola sigue procesándose.
  4. Compara la última marca anterior a la falla, una muestra del periodo desconectado y la primera marca posterior a la recuperación.
  5. Cuenta registros por día o por empleado para detectar huecos. Si el software permite filtrar por dispositivo, usa ese dato para limitar la revisión.
  6. Revisa duplicados. Una importación manual combinada con una sincronización automática posterior puede insertar el mismo evento más de una vez si el sistema no deduplica por identificador y fecha/hora.
  7.  Valida usuarios no reconocidos o IDs inconsistentes antes de cerrar nómina. No reasignes masivamente eventos sin evidencia.
  8.  Documenta la fecha de recuperación, cantidad de eventos pendientes procesados, diferencias encontradas y correcciones autorizadas.

 

Criterio de cierre

La incidencia puede darse por cerrada cuando: todos los dispositivos vuelven a comunicar, el periodo afectado está presente en el software, no existen huecos o duplicados sin explicar, la hora es consistente y cualquier corrección manual conserva motivo y responsable.

 

Cómo evitar duplicados y registros faltantes

Los errores de sincronización suelen aparecer en la relación entre identidad, tiempo y origen. Una empresa puede tener todas las marcas y aun así producir un reporte incorrecto si el mismo empleado existe con dos IDs o si un lote se importa dos veces.

 

¿Qué pasa si la memoria local está cerca de llenarse?

Cuando una sede permanece desconectada durante demasiado tiempo, la capacidad de eventos se convierte en un factor crítico. No existe una regla universal sobre qué hará cada modelo al llegar al límite: puede depender de firmware y configuración. Por eso no conviene esperar a descubrirlo en producción. La política debe establecer un umbral preventivo para recuperar comunicación o extraer un respaldo antes de agotar el almacenamiento.

 

Fuentes de capacidades: ZKTeco Tienda Oficial (s. f.-a, s. f.-b, s. f.-c, s. f.-d, s. f.-e, s. f.-f). Las cifras corresponden a páginas comerciales revisadas en agosto de 2026 y deben verificarse contra la ficha técnica del modelo y firmware efectivamente utilizados.

 

BioTime Cloud y BioTime Pro: cómo pensar la continuidad

En una arquitectura con BioTime, la continuidad tiene dos niveles: que el reloj conserve los eventos y que el software pueda recibirlos y procesarlos cuando la comunicación regrese. BioTime Cloud 2.0 se ofrece como servicio en la nube y centraliza dispositivos compatibles, horarios, incidencias y reportes; BioTime Pro se presenta como plataforma web centralizada para múltiples dispositivos y sucursales. La elección cambia quién administra infraestructura, respaldos y conectividad, pero en ambos casos la empresa necesita procedimientos de recuperación (ZKTeco Tienda Oficial, s. f.-g, s. f.-h).

Antes de implementar, solicita una prueba explícita de pérdida y recuperación de red. No basta con una demostración con internet estable. Desconecta temporalmente un equipo de prueba, genera varias marcas, restablece comunicación y confirma cuánto tarda en aparecer el backlog, cómo identifica el origen y qué sucede si un evento ya fue importado por otro medio.

Prueba de continuidad que deberías hacer antes de producción

  • Desconecta la red del reloj sin cortar energía.
  • Registra varias entradas y salidas con usuarios de prueba.
  • Confirma que los eventos existan localmente.
  • Mantén la desconexión el tiempo suficiente para simular una incidencia realista.
  • Restablece la red y mide el tiempo de reconexión.
  • Verifica que todos los eventos aparezcan en el software con hora correcta.
  • Repite una importación manual solo en un ambiente de prueba para conocer el comportamiento ante duplicados.
  • Genera el reporte de asistencia y confirma que el turno nocturno, retardos e incidencias sigan calculándose correctamente.

Continuidad cuando el problema no es la red, sino la energía

Si el dispositivo pierde energía, no puede generar marcas. En ese escenario la memoria local no resuelve el periodo sin alimentación. Una instalación crítica debe evaluar fuente, contacto, respaldo eléctrico y tiempo de autonomía. El tamaño de un UPS no se define únicamente por el reloj: si existen switch, punto de acceso, router o cerradura asociados, la continuidad de comunicación puede depender de varios equipos.

La política de contingencia debe indicar cuándo pasar a registro alterno y cuándo regresar al checador. Al restaurar energía, valida fecha y hora antes de aceptar las primeras marcas, especialmente si el dispositivo estuvo apagado durante un periodo prolongado o si su reloj interno perdió sincronización.

Marco laboral mexicano: por qué la trazabilidad importa

Para efectos probatorios, el artículo 804 de la Ley Federal del Trabajo incluye los controles de asistencia, cuando se lleven en el centro de trabajo, entre los documentos que el patrón debe conservar y exhibir en juicio. Para los documentos de las fracciones II, III y IV, la ley establece su conservación durante el último año y un año después de que se extinga la relación laboral (Cámara de Diputados del H. Congreso de la Unión, 2026, art. 804).

 

 

Además, el decreto publicado el 1 de mayo de 2026 adicionó la fracción XXXIV al artículo 132 de la LFT para incorporar el registro electrónico del inicio y la finalización de la jornada. El propio decreto prevé que las disposiciones generales de la STPS que determinen el ámbito de aplicación y las excepciones entren en vigor a partir del 1 de enero de 2027 (Diario Oficial de la Federación, 2026).

Por sí sola, una interrupción de red no demuestra que se hayan perdido las marcas: un sistema puede conservar eventos localmente y sincronizarlos después. Sin embargo, tampoco debe asumirse que cualquier modo offline satisfará las disposiciones que emita la autoridad. La empresa debe conservar evidencia de la contingencia, proteger los registros originales y validar la integridad de la recuperación antes de cerrar incidencias o nómina.

Privacidad: cuidado con los respaldos de contingencia

Durante una recuperación es común exportar usuarios, registros o archivos de respaldo. Esos archivos pueden contener datos personales y, según el sistema, fotografías o plantillas biométricas. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares exige principios de licitud, finalidad, proporcionalidad, información y responsabilidad, además de medidas de seguridad. Un respaldo no debe terminar en una memoria USB sin control, un correo personal o una carpeta compartida abierta solo porque surgió una emergencia (Cámara de Diputados del H. Congreso de la Unión, 2025).

Define dónde se guarda el respaldo, quién puede abrirlo, cuándo se elimina y cómo se documenta su uso. La contingencia técnica no elimina las obligaciones de protección de datos.

Errores comunes al recuperar un reloj checador sin conexión

  • Asumir que “offline” significa que todas las checadas se perdieron y capturarlas manualmente antes de revisar memoria local.
  • Restablecer de fábrica el equipo porque no aparece en el software.
  • Cambiar la IP sin documentar gateway, DNS, servidor o VLAN anterior.
  • Corregir la hora después de días de desfase sin analizar qué eventos ya fueron generados.
  • Borrar los registros del reloj inmediatamente después de que vuelve a conectar, sin comprobar el periodo completo.
  • Importar por USB y después permitir que la sincronización automática vuelva a enviar el mismo lote sin revisar duplicados.
  • Usar IDs distintos para la misma persona al reconstruir usuarios.
  • Cerrar nómina con un dashboard incompleto mientras todavía existen eventos pendientes de sincronizar.
  • Desactivar el firewall o exponer el dispositivo directamente a internet como solución permanente.
  • No documentar la causa raíz; la misma falla reaparece semanas después y vuelve a generar una conciliación manual.

Cómo prevenir la próxima desconexión

La mejor contingencia es la que se diseña antes de la falla. Un sistema de asistencia conectado debería incluir monitoreo básico, responsables y una revisión periódica de capacidad y sincronización.

  • Documenta IP, MAC, modelo, firmware, sede, software y método de comunicación de cada reloj.
  • Define quién recibe la alerta cuando un dispositivo deja de sincronizar y en cuánto tiempo debe revisarlo. Si la plataforma permite monitorear la última comunicación, establece un umbral para detectar la caída antes del cierre de nómina.
  • Evita depender de una sola persona que conoce la configuración. Documenta responsables, limita cuentas administrativas y evita contraseñas predeterminadas o compartidas entre sedes.
  • Prueba la recuperación de red al menos durante el piloto y después de cambios importantes de infraestructura.
  • Revisa que los dispositivos estén sincronizando antes de cada cierre de nómina, no después.
  • Mantén una política de respaldo de software y de exportación histórica separada de la memoria del reloj.
  • Planifica crecimiento: más usuarios, más marcas y más sucursales reducen el margen de una arquitectura que estaba dimensionada al límite.
  • Actualiza firmware solo con procedimiento, respaldo y ventana de mantenimiento; no durante una contingencia sin diagnóstico.

Cuándo conviene pedir soporte técnico

Si el reloj tiene red pero no aparece en el software, si los eventos pendientes no suben después de restablecer comunicación, si existe una diferencia importante de hora, si el equipo se acerca al límite de memoria o si la empresa no puede determinar si una importación generará duplicados, conviene detener cambios y solicitar soporte.

 

 

Para acelerar el diagnóstico, comparte modelo exacto, versión de firmware, software y versión, sede, tipo de conexión, IP/red, fecha de la última sincronización correcta, cantidad aproximada de eventos pendientes y cambios recientes de router, switch, firewall o proveedor de internet. Esa información reduce pruebas innecesarias.

 

Antes de solicitar ayuda

No envíes bases de empleados, fotografías o plantillas biométricas por canales no autorizados. Comparte primero información técnica y, si soporte necesita archivos, utiliza el mecanismo seguro definido por el proveedor o por TI.

 

Conclusión: una desconexión debe ser una contingencia, no una pérdida de control

Un reloj checador sin conexión puede seguir siendo útil si mantiene energía, hora correcta y capacidad local para registrar eventos. El problema aparece cuando la empresa no sabe cuánto tiempo lleva offline, cuántas marcas están pendientes o cómo conciliarlas al regresar. Por eso, continuidad significa algo más que “funcionar sin internet”: implica saber qué se almacena, cuánto cabe, cómo se recupera y cómo se demuestra que el reporte final conserva la secuencia real.

La recuperación correcta comienza conservando evidencia y evitando acciones destructivas. Después se identifica si la falla está en Wi-Fi, TCP/IP, servidor, ADMS/PUSH, licencia o infraestructura. Finalmente, la sincronización se valida con conteos, muestras, usuarios, fecha/hora y revisión de duplicados antes de cerrar incidencias o nómina.

Si tu empresa depende de BioTime Cloud, BioTime Pro u otra plataforma central, incluye la prueba de pérdida de red dentro del piloto. Genera checadas offline, restablece comunicación y confirma que el sistema recupere el periodo completo. Esa prueba permite conocer el comportamiento real del modelo y convierte una futura caída de red en un procedimiento controlado en lugar de una emergencia administrativa.

Preguntas frecuentes sobre relojes checadores sin conexión

¿Se pierden las checadas si el reloj se queda sin internet?

No necesariamente. Muchos terminales almacenan eventos localmente y los sincronizan después, según modelo, firmware y software. Debe confirmarse que el equipo siga registrando y que tenga capacidad disponible.

¿Puedo seguir checando si BioTime Cloud no está disponible?

Depende del terminal. Si el equipo valida y almacena localmente, puede continuar capturando eventos aunque la plataforma no los muestre en tiempo real. La recuperación debe probarse previamente.

¿Qué hago primero si el reloj aparece offline?

Confirma energía, si acepta una checada local y la hora del dispositivo. Después documenta la última sincronización y revisa red antes de resetear o borrar configuraciones.

¿Conviene reiniciar de fábrica para recuperar conexión?

No como primera medida. Un restablecimiento puede borrar información y configuración. Primero diagnostica IP, gateway, Wi-Fi, servidor, firewall, firmware y compatibilidad.

¿Cómo sé si los registros pendientes ya se sincronizaron?

Compara la última marca previa a la falla, varias marcas del periodo offline y la primera posterior. También revisa conteos por día/empleado y, cuando sea posible, por dispositivo.

¿Puede haber registros duplicados después de reconectar?

Sí, especialmente si durante la falla se importaron archivos manualmente y después el dispositivo vuelve a enviar los mismos eventos. El comportamiento depende del software; debe probarse la deduplicación.

¿Qué pasa si el reloj se queda sin luz?

Sin energía el equipo no puede capturar nuevas marcas. Debe existir un procedimiento alterno y, si la operación lo requiere, respaldo eléctrico para reloj y elementos de red asociados.

¿Cuánto tiempo puede funcionar un checador offline?

No hay una duración universal. Depende de capacidad local, cantidad de marcas diarias, energía, hora interna y comportamiento del modelo. La capacidad publicada debe tratarse como un buffer, no como permiso para operar indefinidamente sin supervisión.

¿Debo borrar los registros del dispositivo después de sincronizar?

Solo conforme al procedimiento del fabricante y después de comprobar que la información esté respaldada. No borres de inmediato la evidencia de una contingencia.

¿El registro electrónico de jornada de 2027 exige internet permanente?

No lo establece de forma expresa. El decreto de 2026 incorpora la obligación de registro electrónico y deja a la STPS definir el ámbito de aplicación y las excepciones mediante disposiciones generales. Por ello, no debe suponerse que exige internet permanente ni que cualquier modalidad offline será suficiente hasta revisar las reglas aplicables.

¿Qué datos debo enviar a soporte?

Modelo, firmware, software, sede, tipo de red, última sincronización correcta, estado actual, cantidad aproximada de eventos pendientes y cambios recientes de infraestructura. Evita compartir datos personales innecesarios por canales no autorizados.

Referencias

Nota legal. Este artículo es informativo y no sustituye asesoría laboral, jurídica, de protección de datos, redes o tecnologías de la información. El comportamiento offline, la sincronización y la retención dependen del modelo, firmware, plataforma y configuración. Las obligaciones concretas pueden cambiar conforme a disposiciones de la autoridad.

Related Posts

HomeCategoriesAccount
0 Cart
Search