Avisar antes de quedarse sin cuota de consultas de multas

Avisar que la cuota está por agotarse sirve sólo si queda tiempo para actuar. El nivel consumido no alcanza: hacen falta ritmo, fecha proyectada, un destinatario con nombre y una acción escrita.

Por Marco Ferreiro · 2026-09-10

Frasco de vidrio con granos oscuros a poco más de un tercio de su altura sobre una mesada de madera, con una cuchara medidora al lado y luz natural.

Una integración de flota funciona sin sobresaltos hasta que, un martes a la mañana, las consultas empiezan a ser rechazadas y la empresa se entera por un reclamo del mostrador. La cuota no se agotó esa mañana: se agotó a lo largo del período, sin que nadie mirara el saldo.

Conviene separar dos señales. El rechazo por límite es una respuesta del servidor: RFC 6585 define 429 Too Many Requests para las solicitudes que exceden lo permitido en un período, y cuando llega, la decisión ya está tomada del otro lado y la patente quedó sin consultar. La alerta de consumo es un aviso propio, anterior a ese punto, que existe para dejar tiempo de actuar.

Ese margen define el diseño. Una alerta que avisa cuando ya no queda tiempo para pausar un barrido de patentes, repriorizar el trabajo o pedir una ampliación no es una alerta: es un registro tardío con notificación.

De dónde sale el saldo

Conviene tener dos fuentes. La primera es lo que publica el proveedor: el grupo HTTPAPI del IETF mantiene un borrador que define campos RateLimit para comunicar la política vigente y la disponibilidad restante. Sigue siendo un Internet-Draft, su presencia depende de cada proveedor y sus valores son orientación, no una garantía.

La segunda es el contador propio, el único auditable puertas adentro y el único que permite atribuir el gasto a un equipo o a una flota.

Ambas tienen que hablar de la misma unidad y de la misma ventana. Si el contrato cuenta por patente consultada y el contador local cuenta solicitudes HTTP, el saldo de la alerta no es el que el proveedor va a hacer valer. Si la ventana local cierra con otro huso horario, el aviso se corre. Y un "restante cero" no significa lo mismo en una política por minuto que en una cuota mensual; esa lectura fina la tratamos en rate limits interpretables.

Nivel, ritmo y proyección

El umbral clásico dispara cuando el consumo cruza cierta proporción del plan. Es un dato de nivel: dice cuánto se usó, no cuándo se termina. Cruzarlo temprano con consumo parejo puede ser normal; cruzarlo con el ritmo en alza y la ventana por cerrar, no.

Lo accionable es la proyección: con el saldo actual y el ritmo reciente, en qué fecha se agota. Un aviso que dice "a este ritmo la cuota termina antes del cierre" habilita una decisión; uno que dice "consumo alto" obliga a rehacer la cuenta.

Conviene combinar dos disparos, porque miran cosas distintas:

uno lento sobre la proyección, que avisa cuando el margen en días cae por debajo de lo que tarda la acción más lenta;
uno rápido sobre el salto abrupto, que detecta un lote arrancado sin techo antes de que la proyección lo refleje.

Proyectar sobre pocas patentes produce fechas que cambian todos los días, así que ambos necesitan un piso de volumen.

La métrica que la sostiene

La alerta no es mejor que el contador que la alimenta: conviene que sea acumulativo, nombrado con su unidad, y que el ritmo se derive de él. La ventana de la cuota se modela aparte, porque el reinicio contractual no siempre coincide con el del monitoreo.

Las etiquetas útiles son pocas: credencial o equipo, entorno y ventana. Nunca patente, CUIT ni correo. Las recomendaciones de nombres y etiquetas de métricas advierten que cada combinación distinta crea una serie nueva, así que una etiqueta de alta cardinalidad no sólo expone datos: degrada el sistema que tenía que avisar.

Falta el caso que siempre se olvida: la ausencia de datos. Una alerta que sólo dispara al cruzar un valor queda ciega si el contador dejó de actualizarse. El silencio también tiene que avisar.

A quién le llega y qué dice

Una alerta a un canal sin dueño no cambia nada. El destinatario tiene que poder ejecutar la acción esperada: pausar el barrido de la flota, bajar la frecuencia o iniciar una ampliación. Si la acción es comercial, necesita más anticipación: una aprobación interna tarda más que apagar un proceso.

El contenido mínimo es saldo, unidad, ventana, ritmo, fecha proyectada y la acción esperada. Sin esa última línea, cada notificación se vuelve una investigación. El reparto entre áreas lo tratamos en cuota de consultas.

Qué verificar antes de confiar en el aviso

Antes de dar la alerta por hecha, revisá:

que la unidad y la ventana coincidan con las del contrato;
que la anticipación alcance para la acción más lenta, no sólo la más rápida;
que exista un disparo por ausencia de datos;
que cada alerta tenga destinatario con nombre y acción escrita.

La prueba se hace bajando el umbral en un entorno controlado y confirmando que el aviso llega, dice lo que tiene que decir y no se repite. Descubrirlo mal configurado durante el evento real agrega una falla a la otra.

Cuando la anticipación no alcanza, queda la reacción: respetar la espera que el servidor indique con Retry-After, que RFC 9110 define en segundos o como fecha. Pero eso ya es administrar el agotamiento con la flota sin consultar; la alerta existe para que no haga falta.

Metodología

Alcance: Diseño de alertas internas sobre el consumo de una cuota contratada de consultas, antes del agotamiento. No cubre precios, planes comerciales ni la configuración de una herramienta de monitoreo en particular.
Unidad de análisis: Una consulta imputada a una credencial dentro de la ventana de cuota vigente.
Cobertura: La semántica de 429, Retry-After y los campos RateLimit proviene de los estándares y el borrador citados; los criterios de nombres y etiquetas, de la documentación de métricas citada. Los umbrales son patrones de gestión interna.

Limitaciones

Los campos RateLimit siguen siendo un Internet-Draft: cada proveedor decide si los publica y con qué partición.
Los umbrales y la ventana de proyección dependen del volumen y la estacionalidad de cada integración; no hay un valor universal recomendable.
La nota no evalúa herramientas de monitoreo ni funciones de aviso de un proveedor determinado.

Fuentes

Internet-Draft activo — RateLimit header fields for HTTP — Internet Engineering Task Force (consultada el 2026-08-29)
RFC 6585 — Additional HTTP Status Codes — RFC Editor (consultada el 2026-08-29)
RFC 9110 — HTTP Semantics — RFC Editor (consultada el 2026-08-29)
Recomendaciones de nombres y etiquetas de métricas — Prometheus (consultada el 2026-08-29)

Preguntas frecuentes

¿Alcanza con esperar el 429 para enterarse de que la cuota se agotó?

No, y además puede confundir. Un 429 indica que las solicitudes excedieron una política del servidor, que puede ser un límite de ritmo en una ventana corta y no la cuota contratada. Para cuando llega, la decisión ya está tomada del otro lado: el aviso propio tiene que ser anterior.

¿Qué umbral conviene configurar para avisar?

El que deje tiempo para la acción más lenta que la alerta habilita. Si pausar un proceso por lotes lleva minutos pero ampliar el plan pasa por una aprobación interna, un único umbral tardío sirve para lo primero y llega tarde para lo segundo. Conviene combinar el nivel consumido con el ritmo reciente.

¿Los campos RateLimit del proveedor alcanzan para armar la alerta?

Ayudan cuando existen, pero no alcanzan solos. Siguen siendo un Internet-Draft, cada proveedor decide si los publica y sus valores son orientación sobre una política, no una garantía. Un contador propio por credencial permite atribuir el consumo y detectar diferencias con lo que informa el proveedor.

¿Cada cuánto conviene repetir un aviso de consumo?

Una notificación por umbral y por ventana, rearmada cuando la ventana se reinicia, más un aviso cuando la situación se normaliza. Un umbral que repite cada pocos minutos termina silenciado, y el silencio suele sobrevivir hasta el evento que sí importaba.