La prova de la caiguda ha de sortir del correu que estava caigut

Mentre escrivim això, la caiguda de Microsoft 365 que va començar ahir a la tarda continua oberta i sense hora estimada de tornada. D'això ja hi ha cent cròniques. Anem a la part dels diners: això es paga. L'acord de nivell de servei preveu un crèdit, però no s'abona sol, no es calcula amb el rellotge de la notícia i —si vas comprar el teu Microsoft 365 a través d'un tercer, com la majoria de les pimes espanyoles— no ets tu qui el demana. I la prova que Microsoft exigeix per pagar-lo li ha d'arribar en un correu enviat des del domini de l'inquilí afectat. És a dir: des de la bústia que estava caiguda.

On som a les vuit del matí

Dos identificadors, que són els que importen per a tota la resta: EX1550543 per a Exchange Online i MO1550821 per a la resta de la suite. Va començar dijous 12 a la tarda en hora europea, amb usuaris que no podien connectar amb les seves bústies «a través de múltiples mètodes de connexió» a Amèrica, i es va estendre. La pàgina d'estat de Microsoft ha anat llistant Exchange Online, Teams, SharePoint Online, Copilot, Defender, Planner, To Do, Intune, Purview i Power BI. Microsoft ha escrit que no hi ha indicis d'activitat maliciosa, i que continua investigant què va disparar els errors.

De les actualitzacions de Microsoft hi ha tres frases que convé guardar. La primera és una correcció d'ella mateixa: va determinar que la càrrega elevada no venia d'un augment general del trànsit, sinó que una gran quantitat de servidors estava inesperadament no disponible i fallava les comprovacions automàtiques de salut. La segona descriu per què això dura, i aquesta sí entrecomillada: «els servidors que hem retornat al servei poden tornar a quedar-se sense respondre un cop reben trànsit». La tercera explica el que veus tu: Microsoft està restringint temporalment, en algunes ubicacions, quins tipus de trànsit poden arribar a la infraestructura afectada. D'aquí que l'accés sigui intermitent fins i tot en regions que figuren com a recuperades. A les 04:10 GMT d'avui informava de recuperació parcial en algunes regions i afegia que aquelles accions no estaven donant una recuperació sostinguda.

Les dues lectures tècniques que sol tocar fer aquí ja estan publicades i no les repetirem: per què una llista de serveis caiguts alhora és un mapa de dependències compartides que et donen de franc, i per què una màquina que torna al servei i cau en rebre trànsit és el problema de l'arrencada i no el de la restauració. Avui anem a un altre lloc, perquè hi ha una part d'aquesta caiguda que té data de caducitat.

El crèdit és un percentatge de la teva quota, no una indemnització

Per a Exchange Online, l'SLA consolidat de serveis en línia compromet un 99,9% mensual i liquida els incompliments en crèdit sobre la quota d'aquell servei. Els trams són tres: per sota del 99,9%, el 25%; per sota del 99%, el 50%; per sota del 95%, el 100%. El percentatge de disponibilitat del mes no parla d'hores, parla de persones: ((User Minutes − Downtime) / User Minutes) × 100, on el temps caigut és la suma, incident a incident, dels minuts que va durar multiplicats pel nombre d'usuaris als quals va afectar.

Fem el càlcul d'aquest mes. El novembre té 30 dies: 43.200 minuts per usuari. Sobre aquesta base, els tres llindars de l'SLA queden així:

Mira la fila del mig, perquè aquí hi ha el detall que decideix si això val una hora de paperassa o no: el salt del 25% al 50% és a 7 hores i 12 minuts. Una caiguda que arrenca a mitja tarda i passa de matinada aterra just en aquell llindar. I el repartiment per usuaris talla en tots dos sentits: si només la meitat de la teva plantilla es va quedar sense bústia, els teus user-minutes caiguts es parteixen per dos i el mes no baixa del 99% tot i que l'incident duri el mateix. No hi ha un percentatge universal per a aquesta caiguda. Hi ha el teu, i surt de la teva plantilla i del teu rellotge.

Dos aclariments abans que ningú faci plans. El primer: el crèdit es calcula servei per servei, i Microsoft ho il·lustra amb un exemple propi —si el client té una suite Office 365 però només va patir una caiguda de SharePoint, el crèdit s'aprova per a SharePoint i no per al pla sencer—. El segon: un crèdit mai no excedeix la quota mensual d'aquell servei, i el mateix acord diu que no es concedeix per compensar cap altra forma de pèrdua, inclòs el lucre cessant. És un descompte a la factura de Microsoft. L'aritmètica de per què un percentatge de disponibilitat no et diu res sobre quant dura una sola caiguda ja la vam desmuntar a l'octubre.

El que compta com a caiguda està definit sobre l'Outlook Web Access

Aquesta lletra petita ja la vam explicar a l'agost amb un altre incident —hi ha avaries que t'aturen l'oficina i que per a l'SLA no són una caiguda—, així que aquí va curta. L'acord defineix el temps caigut d'Exchange Online com «qualsevol període de temps en què els usuaris no poden enviar o rebre correu amb Outlook Web Access», el nom antic de l'Outlook al web. No diu el client d'escriptori ni el mòbil. Aquesta vegada l'avís de Microsoft parlava de bústies inaccessibles «a través de múltiples mètodes de connexió», així que el web entra en el còmput.

La prova ha de sortir del correu caigut

La documentació de Microsoft per als proveïdors del programa CSP detalla què cal aportar, i aquí hi ha el detall que dóna títol a això. Literal: «aporta evidència que la caiguda va afectar el client i que aquest va sol·licitar crèdit d'SLA. Cal proporcionar l'identificador de l'inquilí del client i l'identificador de la caiguda (del tauler de salut del servei). El correu del client presentat com a evidència ha de venir del domini de l'inquilí afectat. (Un correu d'una adreça personal no és acceptable)».

Llegeix-ho un altre cop pensant en dijous a la tarda. La petició de crèdit per una caiguda de correu corporatiu ha de viatjar pel correu corporatiu. Si la teva gent, amb la bústia morta, va escriure des del seu Gmail de sempre —que és exactament el que fa tothom en una caiguda— aquella evidència no val. No és una trampa ni una maldat: és una comprovació de titularitat bastant raonable des del costat de Microsoft. Però exigeix que algú es recordi d'enviar aquell correu des del domini, tan aviat com el servei doni un respir, i abans que el calendari tanqui la porta.

I no n'hi ha prou amb el correu. La mateixa pàgina avisa que «el nom del client, l'identificador d'inquilí, el número de tiquet del partner i la data i hora de creació del tiquet no són suficients perquè una reclamació es processi», i llista què és el que sí que prova l'impacte: informació sobre l'hora i la durada del temps caigut; el nombre i les ubicacions dels usuaris afectats «si escau»; descripcions dels teus intents de resoldre l'incident en el moment en què passava; un correu del client afectat demanant suport i després l'aplicació del crèdit; i el número de tiquet amb els detalls del contacte amb el client.

Subratllem la tercera perquè és la que no es pot fabricar després. «En el moment en què passava»: què vau provar, a quina hora, amb quin resultat. Si ningú no va apuntar res mentre passava, aquell camp s'omple de memòria dues setmanes més tard, i de memòria totes les caigudes duren «tota la tarda». Les altres quatre coses es poden treure d'un sistema quan calgui. Aquesta cal escriure-la el mateix dia.

Si vas comprar a través d'un tercer, qui reclama no ets tu

Aquesta és la part que descol·loca gairebé tothom, i és una frase sola: «les sol·licituds de crèdit s'accepten únicament de proveïdors directes i indirectes del programa CSP. No s'accepten sol·licituds de revenedors indirectes». Si tens contractat Microsoft 365 amb l'empresa d'informàtica del polígon —que és el cas de mitja Espanya— aquella empresa pot ser perfectament un revenedor indirecte, i llavors Microsoft no li accepta la reclamació a ella tampoc: l'ha de pujar el seu majorista, el proveïdor indirecte que hi ha per sobre.

Així que la cadena real d'aquesta caiguda té tres salts: tu escrius a qui et factura, qui et factura escriu al seu majorista si no la pot presentar ell, i el majorista obre el tiquet a Partner Center amb la teva evidència a dins. A cada salt es pot perdre l'identificador, el GUID de l'inquilí o —sobretot— el correu que havia de sortir del teu domini. Nosaltres no venem llicències de ningú, així que en aquesta cadena no som qui et factura: som qui documenta l'incident i persegueix que la reclamació pugi amb tot a dins. La paperassa d'un tercer no és una excusa acceptable quan el termini el posa un calendari.

El termini: 31 de desembre

El mateix acord ho deixa amb un exemple que no admet interpretació: la reclamació ha d'arribar a Microsoft «al final del període següent al mes en què va ocórrer l'incident», i ho il·lustra així —si l'incident va ser el 15 de febrer, la reclamació ha d'estar presentada abans del 31 de març—. Aplicat a això: incident del 12 de novembre, porta tancada el 31 de desembre de 2026. La documentació del canal diu el mateix amb altres paraules —dos mesos des del final del mes de facturació per a Azure, un mes per a tots els altres serveis—. La via per a qui compra directe és el centre d'administració, a Suport, obrint una nova sol·licitud de servei i demanant crèdit d'SLA amb l'identificador de l'incident a dins. Passada la data no hi ha apel·lació possible: no és que t'ho deneguin, és que ja no existeix.

El quadern de la caiguda: sis camps, avui

Això és el que fem nosaltres mentre un proveïdor està caigut, i no té res de sofisticat. És un document compartit, obert al minut u, amb sis camps. L'escriu qui està de guàrdia, no qui després reclama:

1. La teva hora d'inici i la teva hora de tornada, amb el rellotge de casa. En una reclamació el que compta és quan ho vas veure tu; l'hora en què el fabricant ho reconeix sol ser bastant posterior.
2. Quantes persones i on. Nombre i ubicacions. La font ho demana «si escau», i escau sempre que es pugui comptar. «Tota l'empresa» no és un nombre.
3. Què es va provar, amb hora. Outlook d'escriptori, Outlook al web, mòbil, una altra xarxa, un altre navegador, reinici de sessió. Aquesta és la llista que no es pot reconstruir després.
4. L'identificador de l'incident i el GUID de l'inquilí, copiats del teu propi centre d'administració. El prefix de dues lletres diu el servei: EX Exchange Online, SP SharePoint, MO portal. Aquí: EX1550543 i MO1550821.
5. L'historial de l'incident, exportat, no enllaçat. Les actualitzacions del tauler de salut canvien de redacció mentre l'incident viu i acaben arxivades; el PDF o la captura d'avui és la teva versió datada.
6. El correu de sol·licitud, enviat des d'una adreça del teu domini, demanant suport i el crèdit, amb els dos identificadors a dins. És el camp que caduca i l'únic que depèn que el servei et doni una finestra.

Sis camps, un quart d'hora repartit al llarg de l'incident. I un efecte secundari que val més que el crèdit: aquell mateix quadern és l'informe que et demanaran dilluns a direcció, i és la base de la conversa sobre quin canal alternatiu té la teva empresa quan el correu no hi és. Nosaltres ho muntem dins del suport gestionat precisament perquè en una caiguda de proveïdor no hi ha res a arreglar: només cal decidir què s'atura, avisar per un canal que continuï viu i deixar escrit què va passar.

Quan no val la pena

Si sou deu persones amb un pla bàsic, fes el càlcul abans de posar-t'hi: el 25% d'un mes d'un sol servei per a deu llicències és una xifra que no paga ni l'hora de qui omple el formulari. Dir-ho així ens treu feina, però és la veritat. I hi ha un error pitjor que no reclamar, que és deixar que la paperassa es mengi la resposta: si has de triar entre documentar la caiguda i obrir el canal alternatiu perquè la gent continuï treballant, s'obre el canal. El quadern aguanta quinze minuts de retard sense perdre res pel camí.

El cas contrari és el que ens trobem més sovint, i és el que de debò justifica els sis camps: si la teva empresa té el seu propi acord de nivell de servei signat amb els seus clients —qualsevol empresa de programari en té—, ahir no eres només la víctima d'una caiguda aliena. Eres també el proveïdor d'algú, i aquell algú et preguntarà per escrit què va passar, quants dels seus usuaris es van quedar fora i què vas fer mentre passava. Les tres respostes són al mateix quadern. La diferència entre tenir-lo i no tenir-lo no és el crèdit de Microsoft: és si la teva versió d'ahir té hores o té adjectius.

Ningú no munta la seva continuïtat damunt d'un descompte, i el canal alternatiu i la llista d'allò que s'atura quan el correu no hi és es treballen abans de la caiguda següent, no durant. Però de tot el que va deixar la tarda d'ahir, aquesta és l'única peça amb un número, un propietari i una data de venciment. Si gestionem nosaltres el teu Microsoft 365, el quadern és part del servei i la sol·licitud surt amb els dos identificadors a dins. Si no, el correu que cal enviar comença per «sol·licito el crèdit d'SLA corresponent als incidents EX1550543 i MO1550821», surt d'una adreça del teu domini i té fins al 31 de desembre.

Fonts (verificades el 13-nov-2026, 08:00 CET). Microsoft Learn, «Request a credit from Microsoft - Partner Center»: la frase que només s'accepten sol·licituds de proveïdors directes i indirectes de CSP i no de revenedors indirectes; els terminis (dos mesos per a Azure, un mes per a la resta des del final del mes de facturació); la llista d'informació requerida i la d'evidència d'impacte; el requisit que el correu del client vingui del domini de l'inquilí afectat i que una adreça personal no sigui acceptable; l'advertiment que nom, GUID i número de tiquet no basten; l'exemple de la suite amb caiguda només de SharePoint; la nota sobre incidents advisory i sobre que una entrada del tauler indica que un inquilí podria estar afectat; i la taula de prefixos de dues lletres. SLA consolidat de Microsoft per a serveis en línia (edició Worldwide English de l'1-gen-2026, llegida al PDF): 99,9% mensual per a Exchange Online, fórmula del percentatge de disponibilitat sobre user-minutes, definició de temps caigut com «qualsevol període de temps en què els usuaris no poden enviar o rebre correu amb Outlook Web Access», trams de crèdit del 25/50/100%, límit de la quota mensual del servei amb la clàusula que no compensa cap altra forma de pèrdua inclòs el lucre cessant, i la regla de termini amb el seu exemple propi (incident del 15 de febrer, reclamació abans del 31 de març). Actualitzacions del mateix incident EX1550543 / MO1550821 publicades per Microsoft al centre d'administració i a la seva pàgina pública d'estat, recollides per la cobertura del 12 i 13 de novembre de SecurityWeek i de la premsa del sector (les tres frases citades, la llista de serveis afectats, el descartament d'atac i l'estat de les 04:10 GMT). La lectura de la cadena de revenda i els sis camps del quadern són nostres. Nota honesta: el percentatge que correspon a cada inquilí depèn del seu propi còmput de user-minutes, que Microsoft calcula amb la seva definició de temps caigut; res de l'anterior no garanteix un crèdit concret.