docs ▸Vigilar y actuar ▸Monitores

Se ejecuta enWrit CloudDesktop

monitors ▸ vigilar y actuar

Monitores.

Un monitor vigila una página e informa de cambios reales frente a una referencia. En los planes cloud superiores comprueba hasta cada 10 segundos, y un cambio detectado puede disparar un workflow en el momento en que ocurre.

Writ se ejecuta en tus propias cuentas, con tus propias credenciales y datos, en los sitios que estás autorizado a usar.

tipos ▸ dos comprobaciones

Dos tipos de comprobación.

Un target es una URL más un check_type:

check_type	Qué comprueba
`content`	Recupera la página y compara lo que vigilas — un selector, la estructura o una zona de captura — con su referencia almacenada.
`uptime`	Comprueba que la página responde: estado HTTP, tiempo de respuesta, validez del certificado.

El renderizado JS es un interruptor aparte: activa requires_playwright y la comprobación corre en un navegador real en vez de una petición simple. Una comprobación JS pesa 5× una comprobación HTML en el presupuesto de tu plan.

vigilar ▸ tres modos

Qué puede vigilar una comprobación de contenido.

Un target de contenido vigila en uno de tres modos, cada uno con su propia referencia:

Modo	Cómo se detecta el cambio
`selector`	El texto de un selector CSS, con hash y comparado. Sin selector, se vigila la página entera.
`html`	El marcado estructurado, comparado estructuralmente en vez de como texto en bruto.
`visual`	Una zona de captura — `visual_region` es `{x, y, width, height}` — comparada con una imagen de referencia almacenada.

Control de ruido: un ignore_regex puede fijarse en el target y en cada selector — los fragmentos coincidentes se excluyen de la comparación, y contadores o marcas de tiempo dejan de producir falsos cambios.

Extractores

Sobre el contenido de un selector, los extractores convierten la zona en valores con nombre que viajan con el evento de cambio. Cada extractor tiene una key, un indicador multiple opcional y un default_value:

type	Qué extrae
`text`	El contenido de texto del elemento.
`attribute`	Un atributo con nombre del elemento.
`regex`	La primera (o cada) coincidencia de un patrón.
`css`	Una selección CSS anidada dentro de la zona vigilada.
`json_path`	Una ruta dentro de JSON hallado en el contenido vigilado.

Crear uno desde código

En tu propia máquina, los SDKs crean un monitor contra el agente local y leen su historial de cambios:

monitor.ts

import { WritAgent } from "@usewrit/agent-sdk";

const client = new WritAgent();
const mon = await client.monitors.create({ url: "https://example.com/pricing" });
const history = await client.monitors.changes(mon.id, { limit: 50 });
console.log(mon.id, history);

monitor.py

from writ_agent import WritAgent

with WritAgent() as client:
    mon = client.monitors.create({"url": "https://example.com/pricing"})
    history = client.monitors.changes(mon["id"], limit=50)
    print(mon["id"], history)

monitor.go

client, err := writ.Discover(ctx)
if err != nil { log.Fatal(err) }
mon, _ := client.Monitors.Create(ctx, map[string]any{"url": "https://example.com/pricing"})
history, _ := client.Monitors.Changes(ctx, mon.ID, nil)
fmt.Println(mon.ID, history)

monitor.rs

use writ_client::WritAgent;
use serde_json::json;

let agent = WritAgent::discover().await?;
let mon = agent.monitors().create(json!({ "url": "https://example.com/pricing" })).await?;
let history = agent.monitors().changes_with(mon.id, &[("limit", "50")]).await?;

monitor.sh

# Local agent daemon — loopback, wlt_/wlk_ token (use 127.0.0.1, not localhost)
curl -X POST http://127.0.0.1:8131/v1/monitors \
  -H "Authorization: Bearer $WRIT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/pricing"}'

contexto ▸ alrededor de la comprobación

Comprobaciones con sesión, y acción en la misma sesión.

Un target puede llevar el contexto que su página necesita — y entregar la sesión en vivo a un workflow cuando se detecta un cambio:

Campo	Qué hace
`pre_check_workflow_id`	Un workflow que corre antes de la comprobación — típicamente un inicio de sesión — para que la comprobación vea la página que ve tu cuenta.
`on_change workflow`	Un workflow disparado al detectar un cambio. Puede correr en la misma sesión en vivo, actuando sobre el estado exacto que la comprobación acaba de ver.
`persona_id`	La persona cuyo estado de sesión guardado usa la comprobación.
`use_residential`	Encaminar la comprobación por salida residencial donde tu plan lo permita.

cadencia ▸ suelos por plan

Suelos de cadencia — rechazados, nunca redondeados.

Cada plan fija un intervalo mínimo, por separado para comprobaciones HTML y comprobaciones con renderizado JS. Un intervalo por debajo del suelo de tu plan se rechaza con 402 y el código interval_too_short — nunca se ralentiza en silencio hasta el suelo.

Plan	Suelo HTML	Suelo JS
Free	5 min	15 min
Starter	1 min	10 min
Pro	1 min	10 min
Growth	30 s	5 min
Scale / Enterprise	10 s	2 min

Lo que configuras es lo que corre. Si una petición exigiría un plan más rápido, la API lo dice de entrada en lugar de degradar tu monitor en silencio.

Dos puertas separadas acompañan al suelo: un presupuesto ponderado de comprobaciones por minuto sobre todos tus targets (10 en Free, hasta 3000 en Enterprise; una comprobación JS cuenta 5×) que responde 402 budget_exceeded al agotarse — y un máximo estricto de targets por tipo de comprobación.

pipeline ▸ del cambio a la acción

Del cambio a la acción.

Cuando una comprobación aterriza, cada acción disparada ha recorrido el mismo pipeline:

Extraer — Los extractores convierten el contenido vigilado en valores con nombre.
Emparejar — Se reúnen los triggers que observan este target (o este selector).
Construir el contexto — Se ensambla el contexto de plantilla {{…}}: valores extraídos, now / now_date y compañía, change_detected_at, target_id y la URL del target.
Deduplicar — Los triggers sin selector disparan una vez por (trigger, target) y por lote — una comprobación no puede duplicar la misma regla.
Condiciones — Se evalúan las condiciones de cada trigger, más sus salvaguardas: ventanas horarias y periodo de enfriamiento.
Registrar, despachar, resolver — El disparo se registra como pending, las acciones salen, y el registro se resuelve con status, action_results y trigger_count.

Operadores de condición (11): changed, exists, equals, not_equals, contains, not_contains, matches, gt, gte, lt, lte.

plantillas ▸ filtros

Filtros de plantilla.

Dentro de las plantillas {{…}} — mensajes, payloads de webhook, entradas de workflow — los valores pueden pasar por filtros:

Filtro	Qué hace
`default (alias: or)`	Valor de respaldo cuando el valor está vacío.
`upper / lower`	Conversión de mayúsculas/minúsculas.
`trim`	Quitar espacios alrededor.
`truncate:N`	Cortar a N caracteres.
`replace:a:b`	Sustituir a por b.
`round[:digits]`	Redondear un número, opcionalmente a un número de decimales.
`add / sub / mul / div`	Aritmética sobre valores numéricos.
`match:<regex>`	Conservar la coincidencia del patrón (patrones de hasta 512 caracteres).

alertas ▸ nueve canales

A dónde van las alertas.

Las alertas de monitores y triggers se entregan por nueve canales: pushover, email, twilio (SMS), whatsapp, signal, webhook, slack, discord y telegram.

pushoveremailtwiliowhatsappsignalwebhookslackdiscordtelegram

Los destinatarios se direccionan como cadenas "channel:id" — p. ej. ["pushover:1", "email:3"] — así un mismo trigger puede repartirse a varios destinos configurados a la vez. Las entregas webhook salientes van firmadas; consulta webhooks.

siguiente ▸ a dónde ir

Sigue adelante.

Automatizaciones y webhooks — el modelo completo de trigger/acción y las entregas firmadas.
Workflows — qué puede hacer un workflow on_change una vez disparado.
Watch-and-act — la historia de producto alrededor de esta referencia.