Monitoraggio dell'uptime, delle prestazioni e degli errori
Zinn Digital® monitora gli indirizzi web che ci fornite — tempo di attività, Core Web Vitals e utilizzo delle risorse rispetto al piano previsto — e li mostra per ciascun sito nella dashboard. Gli avvisi vengono inviati tramite e-mail, Telegram, Slack o al vostro webhook personale, e la nostra pagina di stato risiede all'esterno della piattaforma, continuando a rispondere anche quando noi non possiamo farlo. Il monitoraggio del tempo di attività e della velocità delle pagine è ora attivo: aggiungete qualsiasi indirizzo web — tre sono gratuiti per ogni account e non è necessario che siano ospitati da noi — e lo controlleremo ogni minuto dall'esterno della nostra rete. Disponibilità: il tracciamento 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 è già attivo oggi.
I pannelli di controllo dell'hosting di solito vi mostrano ciò per cui state pagando. Il nostro vi mostra cosa sta facendo il vostro sito. Ogni sito gestito con noi segnala lo stesso insieme di parametri, sito per sito, senza alcun agente da installare e senza alcuna configurazione complessa.
Verifiche continue di disponibilità per sito, contestualizzate rispetto alla cronologia del sito stesso per distinguere un'anomalia momentanea da un'interruzione reale. Lo stato di operatività è un segnale di primaria importanza su cui la piattaforma interviene, non un grafico che nessuno consulta.
Dati reali sulle prestazioni per ogni sito: le metriche in base alle quali Google effettua effettivamente il posizionamento. Le pagine lente compaiono come una misurazione su cui poter intervenire, accanto ai controlli di memorizzazione nella cache per risolverle.
I log degli errori HTTP e PHP sono disponibili per ciascun sito, quindi un errore irreversibile causato da un aggiornamento errato di un plugin o da una distribuzione non riuscita è qualcosa che può individuare anziché dover tirare a indovinare.
Larghezza di banda per sito, oltre all'utilizzo delle risorse misurato rispetto ai limiti del Suo piano — incluse le statistiche LVE per sito — per consentirLe di visualizzare quale sito è maggiormente sollecitato e se è prossimo a una soglia massima.
Una dashboard che bisogna ricordarsi di aprire non è monitoraggio. Ogni segnale alimenta il livello di notifica della piattaforma e siete voi a scegliere dove farlo arrivare.
Una pagina di stato ospitata sulla stessa infrastruttura che monitora è inutile esattamente nel momento in cui ne avete bisogno. La nostra si trova deliberatamente altrove.
La nostra pagina di stato pubblica è ospitata autonomamente su un'infrastruttura separata, interamente al di fuori della piattaforma: una macchina diversa e un dominio di errore distinto dal piano di controllo e dall'infrastruttura di cui monitora lo stato. In caso di problemi con la piattaforma, la pagina di stato continua a rispondere, poiché nessuno dei componenti da cui dipende è coinvolto nel disservizio.
È personalizzato con il vostro marchio, alimentato dallo stesso monitoraggio che gestisce i vostri avvisi per sito ed è indipendente per progettazione 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 sulla piattaforma non renda indisponibile anche la nostra documentazione.
È la stessa logica applicata al resto della piattaforma: domini di guasto separati, nessun destino condiviso e nulla che possa compromettere contemporaneamente sia l'elemento sia lo strumento utilizzato per diagnosticarlo.
I segnali hanno più valore quando qualcosa può agire su di essi. I nostri sono collegati all'assistente e al server MCP, non bloccati in un grafo.
Quando si inizia ad aprire un ticket, l'assistente esegue innanzitutto una diagnostica in tempo reale sul sito interessato (tempo di attività, errori HTTP e PHP, stato SSL e DNS, limiti di risorse ed errori LVE, segnalazioni di malware, conflitti di plugin, integrità del database e cache), prima ancora dell'intervento di un operatore umano.
Nell'ambito dei Suoi permessi e delle misure di sicurezza della piattaforma, svuoterà la cache, riavvierà i worker PHP, riparerà o rinnoverà l'SSL, riparerà le tabelle del database, disabiliterà un plugin che causa un errore irreversibile o svuoterà la CDN — quindi ricontrollerà il segnale e confermerà se il problema è stato effettivamente risolto.
Se è ancora necessario l'intervento umano, il ticket arriva precompilato con i dati di diagnostica, i tentativi effettuati e ciò che è accaduto — in questo modo l'assistenza parte dai fatti invece di chiederLe di descrivere il sintomo.
Collegate qualsiasi strumento di IA compatibile con MCP e potrà leggere lo stato del sito, i log recenti, le metriche, il tempo di attività e gli errori come risorse, consentendo al vostro agente di eseguire una diagnosi prima di agire, tramite OAuth 2.1 con token revocabili basati su organizzazione e ruolo e un registro di controllo completo.
Il monitoraggio delle prestazioni appartiene agli strumenti che le modificano. Sulla nostra piattaforma si trova tra lo stack di memorizzazione nella cache e il livello SEO.
Dietro la Vostra 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 tag per tenant e dati di audit conservati separatamente.
Le metriche vengono raccolte per servizio, per worker e per tenant, con statistiche LVE per sito provenienti dal livello di isolamento. Ogni esecuzione del flusso di lavoro — provisioning, migrazione, applicazione dei criteri — è visibile end-to-end, motivo per cui una risposta dell'assistenza può essere precisa anziché una supposizione.
Il monitoraggio su larga scala è un problema di volume di dati, ed è quindi progettato come tale. Le metriche ad alto volume sono partizionate nel tempo e aggregate anziché essere conservate per sito e per minuto per sempre, le tracce vengono campionate e i controlli di cardinalità per tenant impediscono che un account rumoroso peggiori i dashboard di tutti gli altri. L'obiettivo del progetto è di un milione di siti, non il numero che gestiamo oggi.
Gli avvisi vengono instradati tramite Alertmanager verso il nostro turno di reperibilità con SLO definiti e monitorati — mantenuti deliberatamente separati dalle notifiche per i clienti sopra indicate, in modo che il rumore operativo non finisca mai nella Sua casella di posta e i Suoi avvisi non siano mai in coda dietro i nostri.
Per sito: tempo di attività, Core Web Vitals e prestazioni, larghezza di banda e utilizzo delle risorse misurati rispetto ai limiti previsti dal vostro piano — incluse le statistiche LVE per sito provenienti dal livello di isolamento. Tutto è visibile nella dashboard per ciascun sito, senza dover installare alcun agente.
Tramite qualsiasi canale collegato: e-mail, Telegram, Slack o il proprio endpoint webhook. Le preferenze di notifica vengono impostate per organizzazione e per utente, consentendo di decidere quali eventi debbano raggiungere determinati canali e persone. Le consegne dei webhook sono firmate con HMAC, ritentate con backoff e registrate, per permettere di ispezionare o riprodurre qualsiasi consegna.
Questo è esattamente ciò che è stato progettato per evitare. La pagina di stato è ospitata autonomamente su un'infrastruttura separata, interamente al di fuori della piattaforma, in un dominio di guasto diverso dal piano di controllo e dalla flotta su cui riferisce — poiché una pagina di stato in esecuzione sull'infrastruttura che monitora è inutile durante un'interruzione del servizio.
È l'obiettivo di uptime in base al quale progettiamo e operiamo, ed è dichiarato come una garanzia sui piani Footprint-Free. Si tratta di un impegno sul modo in cui la piattaforma è ingegnerizzata — risorse di calcolo isolate per sito, servizi stateless scalabili orizzontalmente, domini di errore separati — piuttosto che una misurazione pubblicata della disponibilità passata. Il nostro impegno contrattuale è un aspetto separato e più circoscritto, ed è pubblicato: consulti l'Uptime SLA su /legal/sla, che definisce il livello garantito e i crediti di servizio che eroghiamo in caso di mancato rispetto.
Sì. Lo stato del sito, i log recenti, le metriche, l'uptime e i dati sugli errori sono esposti come risorse tramite il nostro server MCP ospitato, consentendo a qualsiasi strumento di intelligenza artificiale compatibile con MCP — Claude, Cursor, ChatGPT e altri — di leggerli ed eseguire diagnosi prima di agire. L'accesso è basato su OAuth 2.1, limitato all'ambito della Sua organizzazione e al ruolo dell'utente che si connette, revocabile per singolo strumento e ogni azione viene registrata nel registro di controllo. I webhook per i clienti coprono le stesse funzionalità per le integrazioni convenzionali.
I segnali di osservabilità descritti qui fanno parte della piattaforma e sono visibili nella Sua dashboard per i siti che ospita con noi, e il riquadro gratuito SEO Basics — indicizzazione, Trust Flow, Core Web Vitals della homepage — è incluso in ogni piano. Un monitoraggio SEO più approfondito, come il tracciamento del posizionamento e il monitoraggio dei backlink, viene venduto come componente aggiuntivo a pagamento separato, mentre l'ottimizzazione manuale della velocità è un extra acquistabile.
Sì. La prova di Footprint-Free dura 14 giorni, non richiede carta di credito e copre fino a 5 siti: nessun dato di pagamento, nessun impegno. Distribuisca alcuni siti e osservi cosa segnala effettivamente la dashboard prima di decidere.
Iniziate una prova di 14 giorni senza carta di credito e monitorate uptime, Core Web Vitals, errori e utilizzo delle risorse per ogni sito fin dal primo deploy, con avvisi ovunque desideriate. Migrazioni gratuite e garanzia di rimborso di 30 giorni su tutto.
Inizia gratis