Check HTTP(S)

Cosa verifica

Un monitor HTTP(S) richiede l’URL al suo intervallo da ciascuna delle sue regioni. Controlla il codice di stato e, se impostate, una parola chiave o un’espressione regolare nel body, e registra il tempo di risposta. I subcheck opzionali per certificato, header di sicurezza e igiene DNS girano nello stesso monitor, così un host che si guasta apre un solo incident, non quattro.

Da usare quando

• Un servizio ha un endpoint HTTP che risponde quando il servizio funziona: un percorso di health, una home page o una route API.
• La risposta richiede un controllo del contenuto, non solo della raggiungibilità: un codice di stato, una stringa nel body o un pattern.
• Il certificato, la postura degli header e i record SPF, DMARC e CAA del dominio vanno controllati nello stesso monitor, invece che in 3 monitor in più.

Non esegue percorsi nel browser, non fa login e segue al massimo 5 redirect. Per una porta senza HTTP usa il check della porta TCP. Per un certificato che merita un incident tutto suo usa il check del certificato TLS.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Target. Un URL completo di schema (https:// o http://). Prima della richiesta la sonda risolve e valida l’URL e ogni salto di redirect. Rifiuta gli indirizzi loopback, privati, link-local e di metadata cloud, così il monitor non può essere puntato verso una rete interna.

Certificato TLS

Su un URL https, lo stesso monitor giudica il certificato che gli viene servito: l’handshake, la catena, l’emittente e il soggetto. Il modulo attiva questo subcheck per ogni URL https.

Header di sicurezza

La sonda invia una seconda richiesta e ne controlla la risposta per gli header selezionati. Conta solo la loro presenza. Un header mancante è un rilievo di postura, non un disservizio, quindi la gravità predefinita è degraded.

Igiene DNS

La sonda legge SPF, DMARC e CAA del dominio come configurazione. Questi record decidono se la posta del dominio viene recapitata e chi può emettere certificati a suo nome. Il rilievo compare con il risultato e non cambia mai lo stato del monitor.

Come si svolge un check

1. Quando scatta un check, ogni regione compila prima la regex. Una regex non valida chiude il check come errore. Ogni check va in timeout dopo 10 s.
2. Il nodo risolve l’host tramite il proprio resolver e valida ogni indirizzo della famiglia selezionata contro gli intervalli bloccati. Ogni indirizzo riceve poi la propria richiesta, con la connessione fissata a quell’indirizzo.
3. La sonda segue i redirect da sé, al massimo 5 salti. Risolve e valida di nuovo ogni salto prima di richiederlo.
4. La sonda giudica prima il codice di stato, poi la parola chiave e la regex. Legge il body solo se una delle due è impostata, e tutte le asserzioni si combinano in AND.
5. Solo un check https superato con il subcheck del certificato TLS attivo esegue la policy sul certificato, una volta per check. Un check superato o degradato aggiunge la valutazione degli header e il rilievo di igiene DNS come sotto-risultati separati.
6. La regione invia il suo risultato al control plane. La regola di alert decide se un risultato fallito apre un incident una volta raggiunto il quorum. Un risultato degradato resta fuori dalla valutazione degli incident.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Cosa contiene un risultato

Codice di stato

Lo stato finale dopo i redirect, giudicato contro expected_status.

Tempo di risposta

Tempo fino alla risposta, body compreso quando viene letto, per regione e per indirizzo (latency_ms).

Riga di dettaglio

Una riga che dice cosa è successo, per esempio HTTP 200, keyword not found o regex did not match. Nomina anche uno stato inatteso o l’errore di trasporto.

Livello della causa

Se un fallimento è imputabile al DNS del target (nome non trovato) oppure, dopo un lookup riuscito, al target stesso. Ogni altra causa viene riportata come unknown.

Certificato

Common name e nomi alternativi, emittente, date di validità con i giorni rimanenti e stato di fiducia.

Header di sicurezza

Quali degli header richiesti erano presenti e quali mancavano.

Igiene DNS

I rilievi su SPF, DMARC e CAA, per esempio una policy DMARC none o un record CAA mancante.

Regione, famiglia, indirizzo

Ogni risultato porta la regione che l’ha misurato, e un sotto-risultato per famiglia IP e per indirizzo.

Stati e gravità

• okIl codice di stato corrisponde e ogni asserzione regge. Un certificato dentro la sua finestra di avviso mantiene questo stato.
• degradatoUn header di sicurezza manca con la gravità predefinita, oppure una famiglia IP fallisce mentre l’altra risponde.
• downLa richiesta fallisce, va in timeout o viene bloccata, oppure il codice di stato o un’asserzione non corrisponde. Contano anche una policy sul certificato che fallisce (scaduto, handshake rifiutato, emittente o soggetto non corrispondenti) e un header mancante con gravità failed.
• erroreLa configurazione non può girare, per esempio per una regex non valida. Conta come disservizio con gravità critica.

Confermato dal quorum: di default, 2 regioni devono segnalare il guasto prima che si apra un incident. Il default dell’organizzazione richiede 2 regioni e 2 check consecutivi. Un monitor può avere una regola propria con numero o percentuale, check consecutivi e una durata minima.

Piani e limiti

Intervallo minimo

300 s in Free, 60 s in Pulse, 30 s in Sentinel, 15 s in Command e 10 s in Enterprise. Il modulo web offre 30 s, 1 min, 5 min, 15 min e 1 h. I minimi di 15 s e 10 s si raggiungono solo tramite MCP.

Regioni

2 su 6 in Free, 3 su 6 in Pulse e tutte e 6 da Sentinel.

Monitor

10 in Free, 50 in Pulse, 150 in Sentinel, 500 in Command e una quota su misura in Enterprise. Undici tipi di check regionali condividono questa quota, mentre host agent e heartbeat hanno la loro. Un pacchetto di 50 monitor in più costa 39 €.

Confronta tutti i limiti

Dalla pipeline o da un agente

La stessa config funziona nello step di deploy, in un client MCP come Claude Code e nel modulo qui sopra. create_monitor richiede una chiave API valida per tutta l’organizzazione. Se ometti regions, il piano sceglie il suo default.

{
  "name": "Order API",
  "type": "http",
  "interval_seconds": 60,
  "config": {
    "url": "https://orders.example.com/health",
    "expected_status": 200,
    "keyword": "ok",
    "tls_cert": { "enabled": true, "warn_days": 21 },
    "security_headers": {
      "enabled": true,
      "headers": ["strict-transport-security", "content-security-policy"],
      "missing_severity": "degraded"
    },
    "dns_hygiene": { "enabled": true }
  }
}

Ogni interfaccia, con il suo limite

Limiti

• La sonda non esegue percorsi nel browser, non esegue JavaScript e non segue flussi di login. Non invia body nella richiesta né cookie.
• Metodo e header della richiesta si impostano via API o MCP, non nel modulo.
• La sonda segue al massimo 5 salti di redirect, e una catena più lunga fa fallire il check.
• La valutazione degli header di sicurezza controlla la presenza, non i valori.
• La sonda rifiuta i target su indirizzi privati, loopback, link-local e di metadata cloud.
• Non tutte le regioni sondano IPv6, quindi selezionare ipv6 restringe le regioni utilizzabili.

Tipi di check correlati

• Check degli header di sicurezzaPresenza di 5 header di sicurezza su un URL, come monitor a sé con il proprio registro.
• Check del certificato TLSScadenza, emittente e soggetto di un certificato tramite handshake TLS diretto, con un avviso prima della scadenza.
• Check della porta TCPSe una porta accetta una connessione, a scelta con il certificato servito su di essa.
• Check di igiene DNSSPF, DMARC con la sua policy e CAA di un dominio, valutati come postura e mai come disservizio.

Tutti i tipi di check