Moniteurs.

Un moniteur observe une page et signale les changements réels par rapport à une référence. Sur les plans cloud supérieurs, il vérifie jusqu’à toutes les 10 secondes, et un changement détecté peut déclencher un workflow à l’instant où il survient.

types ▸ deux vérifications

Deux types de vérification.

Un target est une URL plus un check_type :

surveiller ▸ trois modes

Ce qu’une vérification de contenu peut surveiller.

Un target de contenu surveille selon l’un de trois modes, chacun avec sa propre référence :

Contrôle du bruit : un ignore_regex peut être posé sur le target et sur chaque sélecteur — les fragments correspondants sont retirés de la comparaison, et compteurs comme horodatages cessent de produire de faux changements.

Extracteurs

Sur le contenu d’un sélecteur, des extracteurs transforment la zone en valeurs nommées qui voyagent avec l’événement de changement. Chaque extracteur a une key, un indicateur multiple optionnel et une default_value :

En créer un depuis le code

Sur votre propre machine, les SDKs créent un moniteur auprès de l’agent local et relisent son historique de changements :

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);

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)

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)

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?;

# 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"}'

contexte ▸ autour de la vérification

Vérifications connectées, action dans la même session.

Un target peut porter le contexte dont sa page a besoin — et confier la session en direct à un workflow dès qu’un changement est détecté :

cadence ▸ planchers par plan

Planchers de cadence — rejetés, jamais arrondis.

Chaque plan fixe un intervalle minimal, séparément pour les vérifications HTML et les vérifications avec rendu JS. Un intervalle sous le plancher de votre plan est rejeté avec 402 et le code interval_too_short — il n’est jamais ralenti en silence jusqu’au plancher.

Deux portes distinctes accompagnent le plancher : un budget pondéré de vérifications par minute sur l’ensemble de vos targets (10 sur Free, jusqu’à 3000 sur Enterprise ; une vérification JS compte 5×) répondu par 402 budget_exceeded une fois épuisé — et un maximum ferme de targets par type de vérification.

pipeline ▸ du changement à l’action

Du changement à l’action.

Quand une vérification aboutit, chaque action déclenchée a parcouru le même pipeline :

1. Extraire — Les extracteurs transforment le contenu surveillé en valeurs nommées.
2. Apparier — Les déclencheurs qui observent ce target (ou ce sélecteur) sont rassemblés.
3. Construire le contexte — Le contexte de template {{…}} est assemblé : valeurs extraites, now / now_date et consorts, change_detected_at, target_id et l’URL du target.
4. Dédupliquer — Les déclencheurs sans sélecteur tirent une fois par (déclencheur, target) et par lot — une vérification ne peut pas doubler la même règle.
5. Conditions — Les conditions de chaque déclencheur sont évaluées, plus ses garde-fous : fenêtres horaires et délai de repos.
6. Journaliser, distribuer, régler — Le tir est journalisé en pending, les actions partent, et le journal se règle avec status, action_results et trigger_count.

templates ▸ filtres

Filtres de template.

Dans les templates {{…}} — messages, payloads de webhook, entrées de workflow — les valeurs peuvent passer par des filtres :

alertes ▸ neuf canaux

Où partent les alertes.

Les alertes de moniteurs et de déclencheurs partent par neuf canaux : pushover, email, twilio (SMS), whatsapp, signal, webhook, slack, discord et telegram.

Les destinataires s’adressent en chaînes "channel:id" — p. ex. ["pushover:1", "email:3"] — un même déclencheur peut donc s’éventer vers plusieurs destinations configurées à la fois. Les livraisons webhook sortantes sont signées ; voir webhooks.

suite ▸ où aller

Continuez.

• Automatisations & webhooks — le modèle déclencheur/action complet et les livraisons signées.
• Workflows — ce qu’un workflow on_change peut faire une fois déclenché.
• Watch-and-act — l’histoire produit autour de cette référence.