Manutenzione significa sapere che il modulo oggi consegna, non che il server risponde 200.

Il percorso di una richiesta fino a una persona, non la disponibilità del server. `GET /api/health/contact` verifica in una sola richiesta due cose: che il token del canale di notifica sia ancora valido — tramite una chiamata reale al fornitore, con timeout di 8 secondi — e che il registro delle richieste possa essere scritto. Risponde 200 quando entrambe sono vere e 503 quando non lo sono. Può chiamarla subito su questo sito: è pubblica, proprio perché non restituisce altro che valori logici.

Perché la parte visibile continua a funzionare. La pagina si carica, il pulsante risponde, il server restituisce 200 su tutte le pagine — si rompe solo l’ultimo anello, che non ha interfaccia. Su questo sito il token del bot di notifica è stato revocato: il fornitore rispondeva `401 Unauthorized`, la route restituiva 500 e la richiesta non veniva scritta da nessuna parte. Tre guasti reali in circa sette ore, visibili solo nel registro errori del processo. Per questo ora il registro viene scritto prima della consegna: anche se la notifica fallisce, la richiesta esiste.

La richiesta è già scritta nel registro con un proprio identificatore, e la seconda riga del registro dice `failed` e il motivo. Al visitatore viene data una risposta distinta — „abbiamo ricevuto la richiesta, ma non siamo riusciti a notificare” — non un falso successo. Il codice di risposta distingue la causa: 502 significa che il fornitore ha risposto male, 503 che mancano le credenziali da noi. Alle 3 del mattino, la differenza tra i due decide se chiamare qualcuno o no.

Non senza gate. La pubblicazione esegue `npm audit` al livello `high` e si ferma alle vulnerabilità di questo livello se non viene confermata esplicitamente la continuazione; verifica prima anche la memoria disponibile del server, con soglia di 500 MB, perché una build avviata su un server stretto lascia l’applicazione bloccata. La build parte da zero: la directory di build e le dipendenze vengono cancellate, l’installazione avviene dal file di lock. Cosa si aggiorna automaticamente e cosa passa attraverso la verifica umana viene stabilito per progetto, non per impostazione predefinita.

Tramite uno script di verifica eseguito dopo la pubblicazione, che apre ogni pagina di prodotto e fallisce se mancano il codice 200, l’ancora delle domande, l’ancora dell’esempio o l’indirizzo canonico. Verifica poi la sitemap — che contenga ogni prodotto e non contenga varianti di lingua che non si possono aprire — e `robots.txt`, per non bloccare le risorse di rendering. Ogni verifica dell’elenco corrisponde a qualcosa che si è già rotto una volta. Lo script viene consegnato insieme al progetto.

Il processo viene riavviato automaticamente oltre la soglia di 500 MB, con 4 secondi di ritardo tra i tentativi e crescita esponenziale, ma si arresta dopo 10 riavvii instabili in un intervallo breve. Questo è importante: un ciclo di crash che si riavvia all’infinito appare sano in una dashboard e consuma il server in silenzio. Preferiamo che il processo resti fermo e visibile.

24 mesi, applicati dal codice, non solo dichiarati: la soglia è una variabile con valore predefinito di 730 giorni, e i file più vecchi vengono eliminati a ogni nuova scrittura, senza uno scheduler che può essere dimenticato. La directory ha permessi `0700`, i file `0600`, e il percorso sta fuori dalla directory di versione, così la cronologia sopravvive alla pubblicazione. L’indirizzo IP non viene conservato per intero: viene troncato a `/24` per IPv4 e `/48` per IPv6, leggendo l’ultimo hop dall’intestazione, non il primo — il primo è inviato dal client e non significa nulla.

Succede, e di solito quelli sono i più costosi. Lo stesso passaggio nel codice che ha riparato il modulo ha evidenziato due cose che nessuno aveva segnalato: il limite di richieste si poteva aggirare completamente, perché si leggeva il primo elemento dall’intestazione degli indirizzi reindirizzati — esattamente quello inviato dal client; e una route che avviava chiamate telefoniche era aperta in forma anonima, a nostre spese, sebbene il componente che la usava fosse stato smontato. Entrambe sono state riparate e verificate in produzione. Quello che non possiamo promettere è di trovare tutto; quello che possiamo promettere è che segnaliamo anche ciò che non avete chiesto.

Non è un servizio di sicurezza con monitoraggio 24 ore su 24 e non è un centro operativo. Non garantiamo una percentuale di disponibilità senza una misurazione che la sostenga — e, per essere chiari, al momento non pubblichiamo una tale cifra per il sito proprio. Non assumiamo la responsabilità di una piattaforma terza a cui non abbiamo accesso. E non trattiamo una pagina che risponde 200 come prova che tutto funzioni: esattamente questo è stato il problema da cui è partito tutto ciò che è scritto sopra.