Uptime garantito

Kinsta non offre hosting ad alta disponibilità (HA), ma garantisce l’uptime tramite un accordo sul livello di servizio (SLA). Su Kinsta, ogni sito sulla nostra piattaforma funziona in un singolo container Linux e il database del sito funziona come servizio all’interno del container del sito, il tutto basato su server ad alte prestazioni di livello aziendale. Non eseguiamo istanze multiple con bilanciamento del carico per ogni infrastruttura del sito.

Per maggiori dettagli sulla nostra infrastruttura e architettura, consulta l’articolo Infrastruttura di hosting WordPress.

Grazie alla flessibilità dell’infrastruttura basata su container, alla gestione proattiva del carico da parte del nostro team di tecnici e a piattaforme cloud leader, 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 ulteriori informazioni, contatta il nostro team vendite.

Periodo di manutenzione

Il periodo di manutenzione di Kinsta è giornaliero, dal lunedì alla domenica, dalle 2:00 alle 5:00 ora locale, in base al fuso orario del data center in cui è ospitato ogni sito. Non inviamo notifiche di monitoraggio se la manutenzione viene eseguita durante questo periodo. Per ulteriori informazioni, consulta l’Accordo sul livello di servizio di Kinsta.

Circostanze che bloccano il monitoraggio dell’uptime

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

• Se hai abilitato l’autenticazione di base, questo genererà un errore 401 per tutte le richieste non autorizzate.
• Il modalità “Sono sotto attacco” di Cloudflare ha un tempo di attesa di 5 secondi per prevenire attacchi DDoS. Ciò non si applica alle richieste HEAD, che restituiranno un errore 503.
• Siti proxy inversi in cui il dominio principale non reindirizza all’URL di destinazione.
• Alcuni casi di cache personalizzata possono causare problemi. Ad esempio, se si memorizza nella cache la richiesta HEAD della stringa di query di Kinsta. Anche i servizi proxy come Sucuri e Cloudflare possono talvolta causare problemi con la cache, a seconda della configurazione.
• Servizio di blocco dei bot: Il nostro monitoraggio dell’uptime utilizza kinsta-bot come user-agent, quindi se lo blocchi con un plugin o un servizio (user-agent deny) questo può causare il fallimento del nostro monitoraggio dell’uptime (questo in genere si traduce in un codice di risposta 406).
• Il blocco degli indirizzi IP del nostro monitoraggio dell’uptime o del paese di origine (blocco geografico) influirà sul nostro monitoraggio. Se configuri queste funzionalità sui server di Kinsta, non è un problema poiché aggiungiamo delle eccezioni.
• Se il dominio principale non risolve l’installazione in cui è stato aggiunto o reindirizza a un altro dominio (elencato nell’elenco dei domini dello stesso sito).
• Quando un sito è in modalità di manutenzione, potrebbe restituire una risposta 503.