TurboSMTP Service Incident of 7 May 2026

Technical post-incident summary

What happened

On 7 May 2026 at 09:00 CET, our monitoring detected a complete loss of reachability for the production environment hosted in our Amsterdam region. The cause was external to TurboSMTP: a fire in a utility room at the data center facility hosting our Amsterdam region forced an emergency, controlled power-down of the data halls on instruction of the local fire brigade. According to initial assessments, servers and storage were not damaged. The entire facility was taken offline for the duration of the emergency and remains offline at the time of writing.

This is the kind of low-probability, high-impact physical event that no single-site infrastructure can absorb. TurboSMTP's production architecture is designed accordingly, with capacity distributed across multiple regions.

Our architecture

TurboSMTP runs on a three-region IBM Cloud deployment operated by our upstream infrastructure provider, IBM Italia S.p.A., with production capacity distributed across Amsterdam, Frankfurt (EU customers and traffic), and a third region outside Europe (non-EU customers and traffic). A documented disaster-recovery (DR) plan, designed and tested for the failure of any one region, governs how traffic is moved between them. The Frankfurt region is configured as the designated failover target for the Amsterdam region, with parallel sending capacity and replicated data.

The DR plan covers:

Re-establishing customer-owned IP subnets on the Frankfurt failover region so existing sender reputation and IP allowlists continue to work transparently.
Bringing SMTP and API endpoints back online in priority order, starting with the highest-volume transactional traffic.
Verifying data integrity before any traffic resumes.

What we did, and when

The DR plan was activated within minutes of the alert. Where the incident timeline ended up longer than we would have wanted, the cause was a single dependency that sits outside TurboSMTP's direct control: a network routing change (the re-advertisement of our Amsterdam IP subnets from the Frankfurt region) that can only be applied by our upstream infrastructure provider. We raised that change immediately, at the highest severity available, and tracked it continuously until it was completed.

Timeline (UTC)

Time	Event
7 May, 07:00	Fire reported at the Amsterdam data-center facility.
7 May, ~07:00	Automated monitoring flags loss of reachability across all Amsterdam-region services. Internal incident declared.
7 May, ~07:30	Crisis committee convened. Customer communication channels opened (status page, social, support). DR plan activated.
7 May, 08:00 onward	Two 24/7 war rooms stood up in parallel: a technical war room (all engineering teams recalled, on continuous rotation) and an operational war room (internal coordination, support, customer communications). The technical war room began working on the worst-case scenario: migration to Frankfurt, accepting the trade-off that some non-core services would be temporarily unavailable during cutover.
7 May, morning	Awaiting the upstream provider's damage assessment and recovery estimate, which would determine whether to wait for the Amsterdam facility to come back online or trigger the full failover.
7 May, late afternoon	In the absence of a credible recovery estimate from the upstream provider for the Amsterdam facility, it became clear that the failover path was the only viable option: core services would be brought up from the Frankfurt failover region, with non-core services to follow once core was stable.
7 May, 22:50	Severity-1 disaster-recovery support case opened with our upstream infrastructure provider, requesting the BGP re-advertisement of our three customer-owned /24 subnets from the Frankfurt region.
8 May, 11:27	Upon request from the upstream provider, full technical specification (subnets, target VLAN, prior configuration history) was provided to the upstream provider.
8 May, 22:13	Upstream provider applies the routing change (~23 hours after case open).
9 May, 00:29	Our network team detects that the new routes are not externally reachable and reports the issue back to the upstream provider. Root cause is identified by the upstream provider as a stale route from a previous configuration.
9 May, 04:02	Upstream provider completes the corrective change.
9 May, 06:12	TurboSMTP confirms working state: SMTP and API sending operational from the Frankfurt failover region. Service restored.
9 May onward	Dashboard and ancillary services are being brought back progressively, in priority order.

What was, and was not, affected

Email delivery (SMTP and API): restored from the Frankfurt failover region. Customer-owned sending IPs and sender reputation preserved. No changes required on customer side.
Data integrity: fully preserved. No customer data was lost, corrupted, or exposed.
Dashboard: brought back online with minor degradation while remaining components are migrated. A small subset of users may need to reset their dashboard password. SMTP credentials and API keys are unaffected.
Auxiliary business operations: remained available throughout the incident, with some functions running in a reduced or delayed mode during recovery. Any residual items are being handled by our support team on a case-by-case basis.

What we are doing next

Core service availability has been restored, but recovery work and the operational review are both ongoing. Specifically:

Independence of our DR plan from upstream response times. The single longest item on the timeline above is a routing change that depended on a third party. We are reviewing architectural options that reduce or eliminate that dependency, including pre-staged routing configurations that can be activated without external coordination.
Tighter SLAs on upstream support. We are formally reviewing the support tier and response-time commitments we hold with our infrastructure provider, in light of how this case was handled, and will adjust contractual arrangements accordingly.
Coordinated disaster-recovery drills with our upstream provider. We will run joint DR exercises with our infrastructure provider, with particular focus on the network-layer failover path that constrained recovery in this incident.
Redesign of the technical procedures that encountered unexpected difficulties. A subset of internal runbooks performed below expectation under the conditions of this incident. These are being rewritten, retested, and re-rehearsed so that the next activation runs more smoothly.
Extension of the architecture and DR plan to non-core services. We are extending the same design and failover playbook to the non-core services (dashboard, ancillary tooling) that experienced longer recovery times in this incident, so that future failovers bring the full surface back online in a single coordinated cutover.
Post-mortem with full root-cause documentation. A complete post-mortem, including updated DR runbooks, will be issued once the upstream provider's own incident report on the routing-change handling is received.

Closing note

For a sending infrastructure provider, availability is the core promise to customers. The architecture we built ahead of this incident did its job: data was preserved, sender reputation was preserved, and a complete recovery path existed. The duration of the impact reflects an external dependency we are now redesigning around, together with internal recovery procedures that need further streamlining for catastrophic datacenter incidents of this scale.

We are grateful to the customers who reached out to us during the event for their patience, and to our engineering and support teams for working continuously across the 48 hours of the incident.

For any specific technical question about how this incident affected your account or your sending, our team is available via live chat, phone, or email.

Incidente di servizio TurboSMTP del 7 maggio 2026

Riepilogo tecnico post-incidente

Cosa è accaduto

Il 7 maggio 2026 alle ore 09:00 CET, i nostri sistemi di monitoraggio hanno rilevato la totale irraggiungibilità dell'ambiente di produzione ospitato nel nostro data center di Amsterdam. La causa è esterna a TurboSMTP: un incendio in un locale tecnico presso il data center che ospita il nostro deployment di Amsterdam ha reso necessario uno spegnimento controllato dell'alimentazione delle sale dati, su disposizione dei vigili del fuoco. Secondo le prime valutazioni, i server e gli apparati di storage non hanno subito danni. L'intera struttura è stata posta offline per tutta la durata dell'emergenza e risulta ancora offline al momento della pubblicazione.

Si tratta del tipo di evento fisico a bassa probabilità e ad alto impatto che nessuna infrastruttura monosito può assorbire. L'architettura di produzione di TurboSMTP è progettata in base a questo principio, con capacità distribuita su più data center.

La nostra architettura

TurboSMTP opera su un deployment IBM Cloud su tre data center gestito dal nostro fornitore di infrastruttura, IBM Italia S.p.A., con capacità di produzione distribuita tra Amsterdam, Francoforte (clienti e traffico UE) e un terzo data center al di fuori dell'Europa (clienti e traffico non UE). Un piano di disaster recovery (DR) documentato, progettato e testato per il guasto di un qualsiasi data center, definisce le modalità con cui il traffico viene spostato tra di essi. Il data center di Francoforte è configurato come destinazione di failover designata per il data center di Amsterdam, con capacità di invio parallela e dati replicati.

Il piano di DR prevede:

Il ripristino delle subnet IP di proprietà del cliente sul data center di failover di Francoforte, in modo che la reputazione del mittente e le allowlist IP esistenti continuino a funzionare in modo trasparente.
La rimessa in servizio degli endpoint SMTP e API in ordine di priorità, a partire dal traffico transazionale a maggior volume.
La verifica dell'integrità dei dati prima della ripresa del traffico.

Cosa abbiamo fatto, e quando

Il piano di DR è stato attivato pochi minuti dopo l'allarme. Laddove la durata complessiva dell'incidente si è rivelata superiore a quanto avremmo voluto, la causa è stata una singola dipendenza esterna al diretto controllo di TurboSMTP: una modifica di routing di rete (la riannunzio in BGP delle subnet IP di Amsterdam dal data center di Francoforte) che può essere applicata soltanto dal nostro fornitore di infrastruttura. Abbiamo richiesto tale modifica immediatamente, al massimo livello di severità disponibile, e l'abbiamo seguita in modo continuativo fino al suo completamento.

Cronologia (UTC)

Orario	Evento
7 maggio, 07:00	Segnalazione di incendio presso il data center di Amsterdam.
7 maggio, ~07:00	Il monitoraggio automatico segnala la perdita di raggiungibilità di tutti i servizi del data center di Amsterdam. Incidente dichiarato internamente.
7 maggio, ~07:30	Comitato di crisi convocato. Aperti i canali di comunicazione con i clienti (pagina di stato, social, supporto). Piano di DR attivato.
7 maggio, dalle 08:00	Attivate in parallelo due war room operative 24/7: una war room tecnica (tutti i team di ingegneria richiamati, in turnazione continua) e una war room operativa (coordinamento interno, supporto, comunicazioni con i clienti). La war room tecnica ha iniziato a lavorare sullo scenario peggiore: la migrazione a Francoforte, accettando il compromesso di una temporanea indisponibilità di alcuni servizi non core durante il cutover.
7 maggio, mattina	In attesa della valutazione dei danni e della stima di ripristino da parte del fornitore di infrastruttura, che avrebbe determinato se attendere il rientro in servizio del data center di Amsterdam o procedere con il failover completo.
7 maggio, tardo pomeriggio	In assenza di una stima di ripristino credibile da parte del fornitore di infrastruttura per il data center di Amsterdam, è risultato evidente che il failover era l'unica opzione percorribile: i servizi core sarebbero stati rimessi in funzione dal data center di failover di Francoforte, con i servizi non core a seguire una volta stabilizzati i servizi core.
7 maggio, 22:50	Aperto un caso di supporto in Severity 1 di disaster recovery con il fornitore di infrastruttura, richiedendo il riannunzio in BGP delle nostre tre subnet /24 di proprietà dal data center di Francoforte.
8 maggio, 11:27	Su richiesta del fornitore di infrastruttura, è stata fornita allo stesso la specifica tecnica completa (subnet, VLAN di destinazione, storia delle configurazioni precedenti).
8 maggio, 22:13	Il fornitore di infrastruttura applica la modifica di routing (~23 ore dopo l'apertura del caso).
9 maggio, 00:29	Il nostro team di rete rileva che le nuove rotte non sono raggiungibili dall'esterno e segnala il problema al fornitore di infrastruttura. La causa è individuata dal fornitore in una rotta residua di una configurazione precedente.
9 maggio, 04:02	Il fornitore di infrastruttura completa la modifica correttiva.
9 maggio, 06:12	TurboSMTP conferma lo stato di funzionamento: invio SMTP e API operativi dal data center di failover di Francoforte. Servizio ripristinato.
9 maggio, in poi	Dashboard e servizi ausiliari vengono progressivamente riportati online, in ordine di priorità.

Cosa è stato, e cosa non è stato, impattato

Invio email (SMTP e API): ripristinato dal data center di failover di Francoforte. IP di invio di proprietà del cliente e reputazione del mittente preservati. Nessun intervento richiesto lato cliente.
Integrità dei dati: pienamente preservata. Nessun dato cliente è stato perso, alterato o esposto.
Dashboard: riportata online con un degrado minimo mentre i restanti componenti vengono migrati. Una minoranza di utenti potrebbe dover reimpostare la password della dashboard. Le credenziali SMTP e le chiavi API non sono interessate.
Operazioni di business ausiliarie: sono rimaste disponibili per tutta la durata dell'incidente, con alcune funzioni operative in modalità ridotta o con ritardo durante il ripristino. Eventuali pendenze residue sono gestite dal nostro team di supporto caso per caso.

Cosa stiamo facendo adesso

La disponibilità dei servizi core è stata ripristinata, ma il lavoro di ripristino e la revisione operativa sono entrambi ancora in corso. In particolare:

Indipendenza del piano di DR dai tempi di risposta del fornitore. La voce più lunga della cronologia sopra è una modifica di routing che dipendeva da terzi. Stiamo valutando opzioni architetturali che riducano o eliminino tale dipendenza, comprese configurazioni di routing pre-attivate, attivabili senza coordinamento esterno.
SLA più stringenti sul supporto del fornitore. Stiamo riesaminando formalmente il livello di supporto e gli impegni di tempo di risposta concordati con il nostro fornitore di infrastruttura, alla luce della gestione di questo caso, e adegueremo di conseguenza i nostri accordi contrattuali.
Esercitazioni di disaster recovery coordinate con il nostro fornitore di infrastruttura. Condurremo esercitazioni di DR congiunte con il fornitore di infrastruttura, con particolare attenzione al percorso di failover a livello di rete che ha vincolato il ripristino in questo incidente.
Riprogettazione delle procedure tecniche che hanno incontrato difficoltà inattese. Una parte dei runbook interni ha avuto un rendimento al di sotto delle aspettative nelle condizioni di questo incidente. Tali procedure sono in fase di riscrittura, ritesting e nuove esercitazioni, in modo che la prossima attivazione si svolga in modo più fluido.
Estensione dell'architettura e del piano di DR ai servizi non core. Stiamo estendendo lo stesso design e lo stesso playbook di failover ai servizi non core (dashboard, strumenti ausiliari) che in questo incidente hanno avuto tempi di ripristino più lunghi, in modo che i futuri failover riportino online l'intera superficie del servizio con un unico cutover coordinato.
Post-mortem con documentazione completa della root cause. Un post-mortem completo, comprensivo dei runbook di DR aggiornati, sarà pubblicato una volta ricevuto il rapporto di incidente del fornitore di infrastruttura sulla gestione della modifica di routing.

Nota di chiusura

Per un fornitore di infrastruttura di invio, la disponibilità è la promessa fondamentale verso i clienti. L'architettura che avevamo costruito prima di questo incidente ha svolto il proprio ruolo: i dati sono stati preservati, la reputazione di invio è stata preservata, ed era disponibile un percorso di ripristino completo. La durata dell'impatto riflette una dipendenza esterna che stiamo riprogettando, insieme ad alcune procedure interne di ripristino che richiedono un ulteriore snellimento per incidenti di data center di questa portata.

Ringraziamo i clienti che ci hanno contattato durante l'evento per la pazienza, e i nostri team di ingegneria e supporto per il lavoro continuativo svolto nelle 48 ore dell'incidente.

Per qualsiasi domanda tecnica specifica su come l'incidente abbia interessato il vostro account o i vostri invii, il nostro team è a disposizione tramite chat dal vivo, telefono o email.