Un 429 significa che un client ha inviato troppe richieste in troppo poco tempo. Come funzionano i rate limit, cosa indica Retry-After, come fare backoff e perché un monitor di uptime può incapparci.
429 Too Many Requests significa che il client ha superato un rate limit: non c’è niente di rotto, e riprovare subito peggiora le cose.
Retry-After indica quanto aspettare, in secondi o come data; gli header X-RateLimit sono una convenzione il cui significato varia da API ad API.
I client dovrebbero rispettare Retry-After, fare backoff esponenziale con jitter, limitare i tentativi e inviare meno richieste.
Chi gestisce un sito dovrebbe rispondere 429 invece di 503 o 403, inviare Retry-After, limitare per chiave dove possibile ed escludere il proprio monitoraggio.
I controlli sintetici testano il tuo sito a intervalli regolari; il real user monitoring misura le visite reali. Come funzionano, che cosa sfugge a ciascuno e da dove iniziare.
Un 403 significa che il server ha capito la richiesta e l’ha rifiutata. Le cause tipiche, cosa possono provare i visitatori, come i gestori del sito trovano la regola che blocca e perché i monitor ricevono 403 che i browser non vedono.
I controlli di uptime chiedono al tuo servizio se è attivo; gli heartbeat aspettano che il tuo job segnali di essere stato eseguito. Come funzionano, cosa non vedono e come combinarli.
Una pagina può rispondere 200 e mostrare comunque un errore, uno shop vuoto o il sito di qualcun altro. Come lo scoprono i controlli delle parole chiave e come scegliere un testo che non dia falsi allarmi.
Il tuo sito è down e devi capire perché. Controlla in ordine DNS, connessione, certificato, CDN, server e applicazione, con un test rapido per ciascuno.
HSTS, Content-Security-Policy, X-Content-Type-Options, protezione dai frame, Referrer-Policy e Permissions-Policy: cosa fa ciascuno e un valore sicuro da cui partire.
Dal 15 marzo 2026 i certificati TLS pubblici hanno un limite di 200 giorni, poi 100 e 47 giorni. Il calendario, cosa cambia per la validazione del dominio e una checklist per prepararti.
Le modifiche DNS non vengono inviate: scadono le copie in cache. Perché la propagazione richiede da pochi minuti a due giorni, come verificarla con dig e come pianificare una modifica.
Come calcolare un error budget a partire da uno SLO, che cosa lo consuma, come funziona il burn rate e come scrivere una error budget policy che il tuo team rispetterà davvero.
La formula dell’uptime, esempi svolti con incidenti e manutenzione, come combinare l’uptime di più componenti e in cosa differiscono uptime, disponibilità e affidabilità.
Un uptime del 99,9% consente 43 minuti e 49 secondi di downtime in un mese medio. Cosa consente ogni livello di nove al giorno, al mese e all’anno, come gli SLA misurano l’uptime, come funzionano i crediti di servizio e come scegliere un obiettivo.
Prova gratuita di 14 giorni · Poi gratis con 5 monitor · Nessuna carta di credito
Aiutaci a migliorare Uptimecheck
Con il tuo consenso, Google Analytics e Microsoft Clarity ci mostrano quali pagine sono utili e dove i visitatori si bloccano. Impostano cookie per un massimo di 13 mesi. Senza il tuo consenso, nessuno dei due viene eseguito. Puoi cambiare idea in qualsiasi momento da Impostazioni cookie in fondo alla pagina. Informativa sulla privacy