Automatización de crawls y alertas
Estabiliza los ajustes de rastreo y la verificación antes de depender de comparaciones y alertas periódicas.
Crawl acotado
Evidencia rastreable
Verificación comparable
Un calendario programa un intento, no un crawl garantizado
Elige frecuencia diaria, semanal o mensual, zona horaria, hora, minuto y día adecuado. El jitter distribuye admisiones. Hay hasta cinco calendarios por sitio. Un calendario no verificado puede guardarse, pero se omitirá como `site_unverified`.
El próximo vencimiento indica cuándo debe intentarse la admisión. No demuestra que se haya creado un run, que el worker haya recogido páginas ni que el informe secundario se haya publicado.
Due y started son eventos distintos
El dispatcher revisa disponibilidad, run activo, capacidad, cuotas, límites mensuales, presupuesto y saldo. Un calendario vencido sin run nuevo no es un éxito silencioso.
El historial debe conservar el intento, el resultado de admisión y el motivo de cualquier omisión. Esa separación distingue una regla de calendario correcta de un bloqueo operativo o financiero.
Lee el motivo exacto del skip
- sitio sin verificar o no disponible
- run ya activo
- capacidad o cuota mensual de organización alcanzada
- límite de runs o presupuesto del calendario alcanzado
- saldo insuficiente para reservar
La ventana mensual sigue la zona del calendario
Los defaults actuales son cuatro runs y 50 € por mes. Separa estimación, reserva y liquidación real, sobre todo con renderizado eligible o required.
Pausa y reanudación recalculan el próximo vencimiento
Pausar borra el vencimiento actual; reanudar calcula otro. El borrado es lógico para no reescribir runs históricos.
Las alertas cubren cambios definidos
Se admiten enlaces rotos nuevos, noindex nuevo, cambios robots, canonical, título o meta description, regresiones structured data y sitemap, caída Health y anomalía bot. Define severidad, umbral, digest por run, diario o semanal y, si conviene, calendario.
Una alerta necesita baseline comparable
La regla usa el run comparable o exitoso anterior. Un run no comparable no se convierte en cambio falso.
Comprueba publicación secundaria, alcance y cobertura de ambos runs. Sin una baseline apta, la ausencia de alerta solo significa que ninguna comparación segura produjo un evento.
Conserva los ID de ambos runs cuando la alerta se convierta en una tarea de corrección.
Usa el historial y la comparación de rastreos para verificar los dos informes detrás de una alerta antes de actuar.
Los destinatarios deben poder actuar
Los máximos actuales son 25 reglas y diez destinatarios por sitio. Mantén una lista pequeña y un responsable de investigar; una alerta no es una decisión asignada automáticamente.
Alinea los accesos y responsabilidades del equipo con las personas encargadas de investigar las alertas.
Evento y entrega tienen evidencia separada
Un run guarda hasta 100 eventos, escanea 1.000 elementos y retiene cinco ejemplos por defecto. La entrega tiene estado propio del proveedor y hasta tres intentos.
Distingue el evento guardado, el correo puesto en cola, el intento del proveedor y la entrega confirmada. Ver una notificación en Crawl Foundry no demuestra por sí solo que cada destinatario la haya recibido.
Reduce ruido sin ocultar el run
La supresión va de 0 a 720 horas y vale 24 por defecto. Umbrales y supresión reducen repeticiones; el run fuente permanece disponible.