99,743% · 30 giorni
111 minuti di tempo di inattività non pianificato, elencati di seguito con la relativa causa. La manutenzione pianificata è esclusa dal conteggio ed elencata separatamente.
Tutto funziona normalmente
Verificato da tre reti esterne alla nostra, ogni sessanta secondi. La disponibilità qui sotto è calcolata dai minuti di incidente, non copiata dallo SLA.
- Componenti operativi
- 10 di 10
- Ultimo controllo
- 03:24 UTC
- Disponibilità, 90 giorni
- 99,894%
- Dall'ultimo evento
- 6 giorni fa
In questo momento
Dieci componenti, ciascuno con la propria misurazione
“Operativo” da solo dice molto poco. Ogni riga riporta il valore effettivamente prodotto dal controllo, così un componente tecnicamente attivo ma lento non può nascondersi dietro un pallino verde.
Tutti i sistemi funzionano normalmente
Ultimo controllo alle 03:24 UTC · nessun evento non pianificato da 6 giorni fa · disponibilità del 99,894% negli ultimi 90 giorni
Server virtuali
Operativo
40 hypervisor che segnalano
Server dedicati
Operativo
Tutti gli chassis operativi
Rete — operatore A
Operativo
BGP stabilito · 0,1 ms di jitter
Rete — operatore B
Operativo
BGP stabilito · 0,5 ms di jitter
Filtraggio DDoS
Operativo
Armato · nessuna mitigazione attiva
Pannello cliente
Operativo
100 ms tempo di risposta mediano
API pubblica
Operativo
75 ms tempo di risposta mediano
Provisioning
Operativo
61 s mediana per il root
Pagamenti
Operativo
Tutte le 8 reti in conferma
Assistenza
Operativo
9 min tempo mediano alla prima risposta
Mediane sugli ultimi cinque minuti, da sonde su tre reti che non sono nostre. Un componente risulta degradato non appena la sua mediana supera il doppio del valore normale — preferiamo segnalare troppo che arrotondare dieci minuti negativi a verde.
Calcolato, non dichiarato
Tre finestre, e i minuti dietro ciascuna di esse
Una percentuale isolata può essere scelta a piacere. Ogni cifra qui è il calcolo aritmetico sull'elenco di incidenti sottostante — modificare l'elenco fa muovere la percentuale, che è l'unica versione di questo numero che vale la pena pubblicare.
99,894% · 90 giorni
137 minuti di tempo di inattività non pianificato, elencati di seguito con la relativa causa. La manutenzione pianificata è esclusa dal conteggio ed elencata separatamente.
99,954% · 365 giorni
241 minuti di tempo di inattività non pianificato, elencati di seguito con la relativa causa. La manutenzione pianificata è esclusa dal conteggio ed elencata separatamente.
Tutto quello che è accaduto
Cronologia degli incidenti, compresi quelli causati da noi
Uno storico che contiene solo manutenzioni pianificate non è uno storico. Ogni voce indica cosa si è guastato, quanto è durato e cosa è stato modificato in seguito, in modo che non accadesse di nuovo allo stesso modo.
-
2026-08-22 · 6 giorni fa
Perdita di pacchetti verso IstanbulParziale · 111 min
Un operatore di transito, l'operatore A, ha instradato per errore uno dei nostri prefissi in blackhole. Ritirato da quell'operatore dopo 51 minuti di diagnosi; piena raggiungibilità un'ora dopo. Il traffico verso ogni altra città non ne ha risentito.
-
2026-07-08 · 2 mesi fa
Coda di provisioning bloccataParziale · 26 min
I nuovi ordini sono stati messi in coda anziché essere elaborati. I server esistenti non sono stati interessati. La causa è stata uno spool pieno sull'host delle immagini, che ora genera un allarme al 70% anziché al 95%.
-
2026-05-05 · 4 mesi fa
Rate limiter dell'API troppo aggressivoParziale · 47 min
Un limite inasprito ha respinto picchi legittimi di tre clienti che stavano costruendo flotte di server. Ripristinato entro un'ora e sostituito con una soglia di burst per token.
-
2026-03-09 · 6 mesi fa
Pannello lento, server non interessatiParziale · 38 min
Una migrazione ha lasciato mancante un indice sulla tabella delle fatture e il pannello ha rallentato drasticamente. Hypervisor, rete e API non sono stati toccati. Sono stati emessi crediti per ogni account che ha aperto un ticket, senza chiedere di dimostrare l'impatto subito.
-
2025-12-28 · 8 mesi fa
Filtraggio attivo, 340 GbpsParziale · 19 min
Un attacco volumetrico contro l'indirizzo di un cliente è stato assorbito a monte. Il filtraggio ha aggiunto circa 2 ms per la durata dell'evento. Nessun null-routing è stato applicato e a nessuno è stato chiesto di andarsene.
Le voci più vecchie di questo periodo vengono conservate e fornite su richiesta anziché pubblicate a tempo indeterminato — una pagina che conserva tre anni di cronologia è una pagina che nessuno legge fino in fondo. I crediti per qualsiasi evento non pianificato vengono applicati secondo lo SLA di disponibilità senza che sia necessario richiederli.
Come viene prodotta questa pagina
Quattro decisioni che rendono questi numeri degni di essere letti
Ognuno di essi fa apparire i nostri dati leggermente peggiori rispetto all'alternativa, ed è proprio così che si può capire che non sono stati scelti per compiacere.
Misurato dall'esterno della nostra rete
Da tre macchine presso altri provider, a Francoforte, Amsterdam e New York. Una pagina di stato interrogata dall'interno del data center che monitora è una pagina che risulta verde durante un'interruzione.
Un componente è degradato prima di essere fuori servizio
Più lento del normale è uno stato che pubblichiamo, non uno che arrotondiamo a "operativo". La maggior parte delle voci qui sotto sono degradazioni, non interruzioni, ed è così che si presenta una cronologia onesta.
La disponibilità viene calcolata, non dichiarata
Le percentuali sopra derivano dai minuti di incidente elencati sotto. Se cambia la cronologia, cambia la percentuale; non esiste un numero separato che potremmo continuare a gonfiare in silenzio.
Questa pagina non è ospitata a Chișinău
Funziona altrove di proposito, in modo che un'interruzione di corrente nell'edificio non porti via anche la pagina che lo segnalerebbe.
Quanto ci costa un mese negativo
Il tempo di inattività viene accreditato, non discusso
Le fasce sono pubblicate, i crediti vengono applicati automaticamente, e le esclusioni sono abbastanza limitate da poter essere lette tutte d'un fiato.