← Todos los artículos
Reliability16 de julio de 20265 min de lectura

Qué debería pasar cuando una publicación falla a las 3 de la mañana

Toda la promesa de programar es que dejas de vigilar. Solo se sostiene si la herramienta distingue un fallo pasajero de un token muerto.

La prueba real de una herramienta de programación no es la publicación que sale. Es la que no sale, mientras todo el mundo duerme.

Dos tipos de fallo

La publicación falla de dos maneras muy distintas, y tratarlas igual es como se pierde la confianza.

  • Recuperable — un límite de peticiones, un tiempo de espera, un tropiezo de la plataforma. Esperar y reintentar lo arregla.
  • Permanente — un token rechazado, un vídeo que la plataforma no acepta, un bot expulsado del canal. Reintentar manda la misma petición al mismo juez.

Reintentar el segundo tipo no es insistencia, es ruido. Además retrasa el momento en que se entera una persona, que es lo único que de verdad lo arreglará.

Primero una pausa, luego una persona

Los fallos recuperables merecen una pausa creciente: cinco minutos, veinte, una hora, tres. Los permanentes deben fallar de inmediato y salir a la superficie con el texto de error de la propia plataforma, no con una disculpa genérica.

La regla que más importa

Un reintento nunca debe publicar dos veces. Si Facebook y Telegram aceptaron la publicación e Instagram falló, el reintento va solo a Instagram.

Eso significa registrar el resultado por plataforma, no por publicación. Es más contabilidad, y es la diferencia entre un reintento que ayuda y uno que enseña tu anuncio por segunda vez al mismo público.

Avisar sin enseñar a ignorar

Una notificación por cada reintento enseña a silenciar las notificaciones. Manda una cuando la herramienta se ha rendido de verdad: ese mensaje significa algo, así que se lee.

Deja de mirar el reloj. Déjate llevar.

Empezar gratis

Seguir leyendo