Uptime garantito

Kinsta non offre un hosting ad alta disponibilità (HA), ma offre una garanzia di uptime supportata da un Service Level Agreement (SLA). In Kinsta, ogni sito sulla nostra piattaforma viene eseguito in un unico container Linux e il database del sito viene eseguito come servizio all’interno del container del sito, il tutto costruito su server ad alte prestazioni e di livello enterprise. Non eseguiamo istanze multiple con bilanciamento del carico di ogni infrastruttura del sito.

Per maggiori dettagli sulla nostra infrastruttura e architettura, è possibile consultare:

• Infrastruttura dell’Hosting di Applicazioni e Hosting di Database
• Infrastruttura dell’Hosting di Siti Statici
• Infrastruttura dell’Hosting WordPress

Grazie alla flessibilità offerta dall’utilizzo di un’infrastruttura basata su container, alla gestione proattiva del carico da parte del nostro team di tecnici e all’utilizzo di piattaforme cloud leader del settore, siamo in grado di offrire una garanzia di uptime supportata da SLA fino al 99,9%. Per i piani personalizzati, possiamo offrire una garanzia di uptime migliorata fino al 99,99%. Per maggiori informazioni in merito, è possibile contattare il nostro team di vendita.

Periodo di manutenzione

Il periodo di manutenzione di Kinsta è ogni giorno, dal lunedì alla domenica, dalle 2 alle 5 del mattino ora locale, in base al fuso orario del data center in cui è ospitata l’applicazione. Non inviamo notifiche di monitoraggio se la manutenzione viene eseguita durante questo periodo. Per maggiori informazioni, date un’occhiata all’Accordo sul livello di servizio di Kinsta.

Circostanze che bloccano il monitoraggio dell’uptime

Per garantire il rispetto della nostra garanzia di uptime, monitoriamo tutti i siti della nostra piattaforma. Quando uno dei nostri monitor di uptime si guasta, i nostri tecnici rispondono immediatamente e lavorano per ripristinare il servizio al sito. Tuttavia, ci sono alcuni scenari in cui la nostra capacità di monitorare l’uptime può essere limitata:

• Se è stata abilitata un’autenticazione di base, tutte le richieste non autorizzate riceveranno un errore 401.
• La modalità “I’m under attack” di Cloudflare prevede un tempo di attesa di 5 secondi per prevenire gli attacchi DDoS. Questo non si applica alle richieste HEAD, che rispondono con un errore 503.
• Siti con proxy inverso in cui il dominio primario non viene reindirizzato all’URL di destinazione.
• Alcuni casi di cache personalizzata possono causare problemi. Ad esempio, se viene messa in cache la query string HEAD di Kinsta. Anche i servizi proxy come Sucuri e Cloudflare possono talvolta causare problemi con la cache, a seconda della configurazione.
• Servizi di blocco dei bot: il nostro uptime monitor utilizza kinsta-bot come user-agent, quindi se lo si blocca con un plugin o un servizio (user-agent deny), il monitoraggio dell’uptime può fallire (in genere il risultato è un codice di risposta 406 ).
• Il blocco dell’indirizzo IP del nostro monitor uptime o del paese di origine (Geo-block) avrà un impatto sul nostro monitoraggio. Se si configurano queste caratteristiche sui server di Kinsta, non è un problema perché aggiungiamo delle eccezioni.
• Se il dominio primario non si risolve nell’installazione in cui è stato aggiunto o ha un reindirizzamento a un altro dominio (elencato nell’elenco dei domini dello stesso sito).
• Quando un sito è in modalità di manutenzione, potrebbe restituire una risposta 503.