429 tarkoittaa, että asiakasohjelma lähetti liian monta pyyntöä liian lyhyessä ajassa. Miten pyyntörajoitukset toimivat, mitä Retry-After kertoo, miten viivettä pidennetään ja miksi käytettävyyden valvonta voi törmätä rajoitukseen.
429 Too Many Requests tarkoittaa, että asiakasohjelma ylitti pyyntörajoituksen; mikään ei ole rikki, ja heti uudelleen yrittäminen pahentaa tilannetta.
Retry-After kertoo odotusajan sekunteina tai päivämääränä; X-RateLimit-otsakkeet ovat käytäntö, jonka merkitys vaihtelee API:sta toiseen.
Asiakasohjelman pitää noudattaa Retry-Afteria, pidentää viivettä eksponentiaalisesti satunnaisuuden kanssa, rajoittaa uusintayrityksiä ja lähettää vähemmän pyyntöjä.
Sivuston ylläpitäjän kannattaa vastata 429 eikä 503 tai 403, lähettää Retry-After, rajoittaa avaimen mukaan, kun mahdollista, ja vapauttaa oma valvontansa.
Synteettiset tarkistukset testaavat sivustoasi aikataulun mukaan, RUM mittaa todellisia käyntejä. Miten kumpikin toimii, mitä kumpikin ei näe ja mistä aloittaa.
403 tarkoittaa, että palvelin ymmärsi pyynnön ja kieltäytyi siitä. Tavalliset syyt, mitä kävijä voi kokeilla, miten ylläpitäjä löytää estävän säännön ja miksi valvonta saa 403:n, vaikka selain ei saa.
Käytettävyystarkistus kysyy palvelultasi, onko se pystyssä; heartbeat odottaa, että työsi ilmoittaa ajautuneensa. Miten kumpikin toimii, mitä kummaltakin jää huomaamatta ja miten ne yhdistetään.
Sivu voi vastata koodilla 200 ja silti näyttää virheen, tyhjän verkkokaupan tai jonkun toisen sivuston. Näin avainsanatarkistukset huomaavat sen ja näin valitset tekstin, joka ei aiheuta turhia hälytyksiä.
Sivustosi on alhaalla, ja sinun on saatava selville miksi. Käy läpi DNS, yhteys, varmenne, CDN, palvelin ja sovellus järjestyksessä, ja jokaiselle on nopea testi.
HSTS, Content-Security-Policy, X-Content-Type-Options, kehyssuojaus, Referrer-Policy ja Permissions-Policy: mitä kukin tekee ja turvallinen arvo, jolla aloittaa.
Julkisten TLS-varmenteiden voimassaolo on rajattu 200 päivään 15. maaliskuuta 2026 alkaen, sitten 100 ja 47 päivään. Aikataulu, mikä muuttuu verkkotunnuksen validoinnissa ja tarkistuslista valmistautumiseen.
DNS-muutoksia ei työnnetä eteenpäin, vaan välimuistikopiot vanhenevat. Miksi leviäminen kestää minuuteista kahteen vuorokauteen, miten sen tarkistaa dig-komennolla ja miten muutos kannattaa suunnitella.
Miten virhebudjetti lasketaan SLO:sta, mikä sitä kuluttaa, miten burn rate toimii ja miten kirjoitat virhebudjetin toimintaperiaatteet, joita tiimisi oikeasti noudattaa.
Käytettävyyden kaava, esimerkkilaskelmat häiriöillä ja huolloilla, useiden komponenttien käytettävyyden yhdistäminen sekä käytettävyyden, saatavuuden ja luotettavuuden erot.
99,9 %:n käytettävyys sallii 43 minuuttia 49 sekuntia katkoaikaa keskimääräisessä kuukaudessa. Mitä kukin yhdeksikkötaso sallii vuorokaudessa, kuukaudessa ja vuodessa, miten SLA:t mittaavat käytettävyyttä, miten palveluhyvitykset toimivat ja miten valitset tavoitteen.
14 päivän ilmainen kokeilu · Sen jälkeen ilmainen 5 valvonnalle · Ei luottokorttia
Auta meitä parantamaan Uptimecheckiä
Luvallasi Google Analytics ja Microsoft Clarity näyttävät meille, mitkä sivut auttavat ja missä kävijät jäävät jumiin. Ne asettavat evästeitä enintään 13 kuukaudeksi. Ilman lupaasi kumpikaan ei ole käytössä. Voit muuttaa valintaasi milloin tahansa sivun alareunan kohdasta Evästeasetukset. Tietosuojaseloste