Monitoraggio di uptime, prestazioni ed errori
Zinn Digital® monitora gli indirizzi web che Lei ci fornisce — disponibilità, Core Web Vitals e utilizzo delle risorse rispetto al Suo piano — e li mostra per ciascun sito nella dashboard. Gli avvisi vengono inviati tramite e-mail, Telegram, Slack o al Suo webhook, e la nostra pagina dello stato si trova al di fuori della piattaforma, così continua a rispondere anche quando non possiamo farlo noi. Il monitoraggio della disponibilità e della velocità delle pagine è attivo ora: aggiunga qualsiasi indirizzo web (tre gratuiti su ogni account, e non dobbiamo necessariamente ospitarlo noi) e noi lo verifichiamo ogni minuto dall'esterno della nostra rete. Disponibilità: il monitoraggio degli errori per singolo sito e le statistiche sulle risorse per singolo sito sono in fase di sviluppo attivo e non sono ancora disponibili. Tutto il resto descritto qui è attivo oggi.
I pannelli di controllo dell'hosting di solito ti dicono per cosa stai pagando. Il nostro ti dice cosa sta facendo il tuo sito. Ogni sito che gestisci con noi segnala lo stesso insieme di segnali, per singolo sito, senza alcun agente da installare e senza bisogno di configurare nulla.
Controlli di disponibilità continui per sito, confrontati con la cronologia del sito stesso affinché un'interruzione momentanea e un blocco reale appaiano diversi. Lo stato di attività è un segnale di primo livello su cui la piattaforma agisce, non un grafico che nessuno legge.
Dati di performance reali per sito: le metriche su cui Google effettivamente basa il posizionamento. Le pagine lente compaiono come misurazioni su cui puoi intervenire, accanto ai controlli di caching che le risolvono.
I log degli errori HTTP e PHP sono disponibili per singolo sito, il che significa che un errore irreversibile causato da un aggiornamento difettoso di un plugin o da un deployment non riuscito può essere individuato direttamente anziché essere solo ipotizzato.
Larghezza di banda per sito, più l'utilizzo delle risorse misurato in base ai diritti del tuo piano, comprese le statistiche LVE per singolo sito, in modo da poter vedere quale sito sta lavorando di più e se è vicino a un limite.
Un pannello di controllo che devi ricordarti di aprire non è un sistema di monitoraggio. Ogni segnale alimenta il livello di notifica della piattaforma e tu scegli dove riceverlo.
Una pagina di stato ospitata sull'infrastruttura che monitora è inutile esattamente nel momento in cui ne hai bisogno. La nostra si trova deliberatamente altrove.
La nostra pagina di stato pubblica è ospitata autonomamente su un'infrastruttura separata, completamente fuori dalla piattaforma: una macchina diversa, un dominio di errore diverso rispetto al pannello di controllo e alla flotta su cui riferisce. Quando qualcosa non va nella piattaforma, la pagina di stato continua a rispondere, perché nulla di ciò da cui dipende si trova all'interno dell'incidente.
È brandizzato, alimentato dallo stesso monitoraggio che gestisce i tuoi avvisi per singolo sito ed è indipendente per scelta anziché per caso. Il frontend pubblico segue lo stesso principio: il sito di marketing e il centro assistenza sono distribuiti separatamente dal cluster del piano di controllo, in modo che un incidente della piattaforma non tiri giù con sé la nostra documentazione.
È lo stesso principio che attraversa il resto della piattaforma: domini di guasto separati, nessun destino condiviso, nulla che possa eliminare contemporaneamente sia la risorsa sia lo strumento che usi per diagnosticarla.
I segnali valgono di più quando qualcosa può agire su di essi. I nostri sono integrati nell'assistente e nel server MCP, non chiusi in un grafico.
Quando inizi ad aprire un ticket, l'assistente esegue prima una diagnostica in tempo reale sul sito interessato — uptime, errori HTTP e PHP, stato di SSL e DNS, limiti di risorse e anomalie LVE, segnalazioni di malware, conflitti tra plugin, integrità del database e cache — prima ancora che venga coinvolto un operatore umano.
Nei limiti dei tuoi permessi e delle linee guida della piattaforma, svuoterà la cache, riavvierà i worker PHP, riparerà o rinoverà il certificato SSL, riparerà le tabelle del database, disabiliterà un plugin che genera errori fatali o pulirà la CDN, per poi verificare nuovamente il segnale e confermare se il problema è stato effettivamente risolto.
Se è ancora necessario un intervento umano, il ticket arriva precompilato con la diagnostica, i tentativi effettuati e i risultati ottenuti; in questo modo l'assistenza parte dai fatti anziché chiedervi di descrivere il sintomo.
Collega qualsiasi strumento di IA compatibile con MCP per consentirgli di leggere lo stato del sito, i log recenti, le metriche, l'uptime e gli errori come risorse, in modo che il tuo agente possa diagnosticare prima di agire, tramite OAuth 2.1 con token revocabili delimitati da organizzazione e ruolo e un registro di controllo completo.
Il monitoraggio delle prestazioni si trova accanto agli strumenti che modificano le prestazioni. Sulla nostra piattaforma si colloca tra lo stack di caching e il livello SEO.
Dietro la tua dashboard si trova lo stesso stack di osservabilità su cui eseguiamo la piattaforma: Prometheus e Grafana per le metriche, OpenTelemetry per il tracciamento distribuito tra motore, flussi di lavoro e driver, e log strutturati centralizzati con etichetta tenant e dati di audit mantenuti separati.
Le metriche vengono raccolte per servizio, per worker e per tenant, con statistiche LVE per sito provenienti dal layer di isolamento. Ogni esecuzione di un workflow — provisioning, migrazione, enforcement — è visibile end-to-end, motivo per cui una risposta dell'assistenza può essere specifica anziché basata su supposizioni.
Il monitoraggio su larga scala è un problema di volume di dati, quindi è progettato come tale. Le metriche ad alto volume sono partizionate temporalmente e aggregate anziché conservate per sito e per minuto all'infinito, le tracce vengono campionate e i controlli di cardinalità per tenant impediscono a un account rumoroso di degradare le dashboard di tutti gli altri. L'obiettivo di progetto è un milione di siti, non il numero che gestiamo oggi.
L'invio degli avvisi viene gestito tramite Alertmanager verso il nostro turno di reperibilità, con SLO definiti e monitorati; il tutto è mantenuto volutamente separato dalle notifiche ai clienti menzionate sopra, affinché il rumore operativo non finisca mai nella tua casella di posta e i tuoi avvisi non si accodino mai ai nostri.
Per sito: disponibilità, Core Web Vitals e prestazioni, larghezza di banda e utilizzo delle risorse misurati rispetto ai limiti del tuo piano, comprese le statistiche LVE per singolo sito provenienti dal livello di isolamento. Tutto ciò è visibile nella dashboard per ogni sito, senza la necessità di installare alcun agente.
Attraverso qualsiasi canale tu decida di connetterti: email, Telegram, Slack o il tuo endpoint webhook personale. Le preferenze di notifica sono impostate per organizzazione e per utente, in modo che tu possa decidere quali eventi raggiungono quale canale e quale persona. Gli invii dei webhook sono firmati con HMAC, ripetuti con backoff e registrati, così puoi ispezionare o rigiocare qualsiasi invio.
È esattamente ciò per cui è stato progettato. La pagina dello stato è ospitata autonomamente su un'infrastruttura separata, completamente fuori dalla piattaforma, in un dominio di errore differente rispetto al piano di controllo e alla flotta che monitora, poiché una pagina dello stato in esecuzione sull'infrastruttura che controlla risulta inutile durante un'interruzione.
È l'obiettivo di uptime a cui ci atteniamo nella progettazione e nell'operatività, ed è indicato come garanzia nei piani Footprint-Free. Si tratta di un impegno sul modo in cui la piattaforma è progettata — calcolo isolato per sito, servizi stateless scalabili orizzontalmente, domini di guasto separati — piuttosto che di una misurazione pubblicata della disponibilità passata. Il nostro impegno contrattuale è una questione distinta e più circoscritta, ed è pubblicato: consultare l'Uptime SLA su /legal/sla, che definisce il livello che garantiamo e i crediti di servizio che riconosciamo in caso di mancato rispetto.
Sì. Lo stato del sito, i log recenti, le metriche, i dati di uptime e di errore vengono esposti come risorse tramite il nostro server MCP ospitato, in modo che qualsiasi strumento di IA compatibile con MCP — Claude, Cursor, ChatGPT e altri — possa leggerli e fare diagnosi prima di agire. L'accesso avviene tramite OAuth 2.1, con ambiti limitati alla tua organizzazione e al ruolo dell'utente che si collega, revocabile per singolo strumento, e ogni azione viene registrata nei log di audit. I webhook dei clienti coprono gli stessi aspetti per le integrazioni convenzionali.
I segnali di osservabilità qui descritti fanno parte della piattaforma e vengono mostrati nella tua dashboard per i siti che ospiti con noi, e il widget gratuito SEO Basics — indicizzato, Trust Flow, Core Web Vitals della homepage — è incluso in ogni piano. Il monitoraggio SEO più approfondito, come il monitoraggio del posizionamento e dei backlink, viene venduto come componenti aggiuntivi a pagamento separati, mentre l'ottimizzazione pratica della velocità è un extra acquistabile.
Sì. La prova di Footprint-Free dura 14 giorni, è senza carta di credito e copre fino a 5 siti: nessun dato di pagamento, nessun impegno. Distribuisci alcuni siti e guarda cosa riporta effettivamente la dashboard prima di decidere.
Inizia una prova gratuita di 14 giorni senza carta di credito e visualizza tempo di attività, Core Web Vitals, errori e utilizzo delle risorse per ciascun sito fin dal primo rilascio, con notifiche dove preferisci. Migrazioni gratuite e una garanzia di rimborso di 30 giorni a supporto di tutto.
Inizia gratis