Monitoraggio dell'uptime, incluso con i Core Web Vitals
Sai quando il sito o il checkout smettono di funzionare e quanto velocemente risponde il server nel resto del tempo.
Aggiungi un monitorIncluso in ogni piano e nella prova gratuita.
Il sito sembra a posto e gli ordini si sono fermati
Il server smette di rispondere e la CDN continua a servire la homepage in cache. Oppure una release rompe il checkout e lascia intatte le altre pagine. Non se ne accorge nessuno finché un cliente non manda un'email per chiedere perché non riesce a pagare.
CoreDash controlla entrambi, nello stesso progetto dei Core Web Vitals.
Un'email e un messaggio Slack quando il sito va giù
Quando il sito va giù o una pagina risponde con lo status sbagliato, ricevi un'email e un messaggio Slack, e un altro avviso appena torna online. Aggiungi le pagine che contano, a partire da homepage e checkout: CoreDash controlla ciascuna ogni 30 minuti.
Un monitor passa a Down solo dopo due controlli falliti di fila da due server diversi, così un singolo intoppo di rete non ti sveglia.

Tutti i siti e le pagine sotto controllo in un'unica lista, con l'uptime degli ultimi 7 giorni e gli eventuali certificati in scadenza entro due settimane.
Vedi il disservizio che la CDN nasconde
La CDN può continuare a servire pagine in cache mentre il server è giù. La homepage si carica ancora, ma clienti autenticati, carrelli e tutte le pagine non in cache restituiscono un errore. CoreDash contrassegna comunque il sito come Down: inserisci l'indirizzo IP del server sotto Advanced quando aggiungi o modifichi un monitor, e ogni controllo interroga anche il server stesso, bypassando la CDN.

Quanto dell'attesa dei visitatori dipende dal server
In questo esempio, circa metà dell'attesa dei visitatori dipende dal server. CoreDash affianca il tempo di risposta di ogni controllo al TTFB dei visitatori reali al p75: circa 950 ms dal checker, con un picco ogni sera, contro 1,92 s per i visitatori.
L'immagine più grande o il titolo non possono comparire prima che il server risponda, quindi qui un LCP più veloce comincia dal server.

Intercetta il checkout che si è rotto con l'ultima release
Dopo una release la homepage può continuare a rispondere mentre il checkout restituisce "page not found", e un monitor sulla homepage non rileva alcun problema.
Qui il checkout ha un monitor dedicato. Ha funzionato per cinque giorni, e da una release di due giorni fa risponde 404, che CoreDash contrassegna come Unexpected status. Anche in questo caso ricevi un'email e un messaggio Slack, e un altro avviso appena il checkout torna a funzionare.

Niente falsi allarmi dal firewall e certificati individuati due settimane prima della scadenza
Un firewall che blocca il checker non fa mai scattare un allarme di disservizio. Il monitor indica Blocked, rimanda alla soluzione e non lo conteggia come downtime.
La lista dei monitor segnala anche ogni certificato in scadenza entro 14 giorni. Un rinnovo dimenticato compare lì due settimane prima che i browser inizino ad avvisare i visitatori.

Cosa succede dopo un crash alle 19:50
Il server smette di rispondere alle 19:50. Alle 20:00 il primo server non riceve risposta e il monitor passa a Failing; per ora non parte nulla. Mezz'ora dopo neanche il secondo server riceve risposta. Il monitor passa a Down e partono l'email e il messaggio Slack.
Al primo controllo che riceve di nuovo risposta, il monitor passa a Up e parte la notifica di ripristino con le stesse modalità. A seconda di quando il server si ferma, ne ricevi notizia da 30 a 60 minuti dopo.
L'uptime nel progetto che il team apre già
Ogni monitor appartiene a un progetto CoreDash, e tutti i membri del progetto lo vedono accanto al LCP, all'INP e al CLS dello stesso sito. È compreso nell'abbonamento che hai già e nella prova gratuita. Chiedi a Claude "il mio sito è andato giù questa settimana?" nella stessa chat in cui chiedi perché il LCP su mobile è salito. Collega Claude a CoreDash.
Quando serve un tool di uptime dedicato
CoreDash controlla ogni 30 minuti da due server in un'unica regione e invia avvisi via email e Slack. Un breve disservizio tra due controlli può sfuggire, e non ci sono status page pubbliche né SMS. Per controlli ogni minuto da più paesi, vale la pena pagare un tool di uptime dedicato.
Per sapere se il sito e il checkout funzionano, e quanto velocemente risponde il server, non ne serve uno. È già tutto nel progetto CoreDash, senza costi aggiuntivi.
Domande frequenti
Il monitoraggio dell'uptime ha un costo aggiuntivo?
No. Ogni abbonamento e la prova gratuita lo includono, e i monitor restano attivi finché resta attivo il progetto. Vedi i prezzi.
Ogni quanto viene controllato il sito?
Due volte all'ora. Un server controlla all'ora esatta, l'altro alla mezz'ora.
Dove vengono inviati gli avvisi?
Agli indirizzi email dei membri del progetto, e su Slack una volta collegato al progetto.
Devo modificare il firewall?
Solo se blocca il checker. Ogni controllo invia lo user agent di CoreDash e il bot token del progetto, e una regola del firewall può lasciarlo passare in base a uno dei due. Come autorizzare CoreDash.
Quanti monitor posso aggiungere?
Fino a 25 per progetto. Un monitor controlla un URL: homepage, checkout e login sono tre monitor.
Serve lo script di CoreDash sul sito per l'uptime?
No. A un monitor serve solo un progetto CoreDash, e i controlli vengono eseguiti comunque. La scheda con il TTFB dei visitatori resta vuota finché non arrivano i dati degli utenti reali dallo script.
Inizia dalla pagina che genera fatturato
Apri Uptime nel progetto CoreDash e aggiungi il checkout. Il primo controllo partirà all'ora o alla mezz'ora successiva.
Aggiungi un monitorNon hai ancora un account CoreDash? Inizia la prova gratuita; il monitoraggio dell'uptime è incluso.