Storing bij Fastly kwam door bug die door bepaalde configuratie naar boven kwam

De grote storing bij cdn-provider Fastly werd veroorzaakt door een bug die kon worden getriggerd als klanten een specifieke configuratie doorvoerden. Dat gebeurde op dinsdag, waardoor grote delen van het internet bijna een uur niet bereikbaar waren.

De bug kwam voor in een update die Fastly op 12 mei had doorgevoerd, schrijft het bedrijf in een update over de storing van dinsdag. Die bug kon worden geactiveerd als klanten van Fastly-diensten een specifieke configuratie in hun eigen stacks doorvoerden. Wat voor configuratie dat is of om wat voor bug het precies ging, is niet bekend. Op dinsdag gebeurde het voor het eerst dat een klant zo'n configuratie doorvoerde, waardoor '85 procent van het Fastly-netwerk foutmeldingen gaf'.

De problemen ontstonden volgens Fastly rond 11.47 uur Nederlandse tijd. Het probleem werd 40 minuten later ontdekt en om 13.00 uur zou 95 procent van alle diensten weer online zijn geweest. Om 19.25 uur heeft Fastly een update doorgevoerd waarmee het probleem zou zijn opgelost. Het bedrijf zegt nog verder onderzoek te gaan doen naar de processen die tot het probleem konden leiden, onder andere waarom de bug niet eerder werd gespot.

Veel grote websites gebruiken content delivery network-provider Fastly om content sneller uit te kunnen serveren. De storing op dinsdag had tot gevolg dat veel populaire websites, zoals Reddit, Twitch, Amazon, StackOverflow en GitHub, onbereikbaar waren.

Reacties (65)

[disjfa]

"Jazeker, was een configuratie. We hebben hem weer goed gezet zodat het probleem niet meer voorkomt"

Klinkt als een uitstekende opmerking zodat je het niet verder hoeft uit te leggen als developer

[bwerg]

We hebben hem weer goed gezet zodat het probleem niet meer voorkomt

Dit is geen goede samenvatting. Ze lijken de configuratie gewijzigd te hebben, of die klant afgesloten te hebben, wat dan ook ("10:27 Fastly Engineering identified the customer configuration"), om zo het acute probleem van onbereikbare websites op te lossen. Daarna hebben ze de daadwerkelijke bug opgelost ("17:25 Bug fix deployment began"), en daardoor zou het niet meer voor moeten komen.

[PdeBie]

Goede management samenvatting inderdaad. Prima ook, want de managers willen al die details niet weten.

[FirePuma142]

Dat is in mijn ervaring heel ouderwets management. De bedrijven waar ik de afgelopen 10 jaar heb gewerkt (voornamelijk financials) zijn juist heel erg detailgedreven, om de juiste tools ter beschikking te kunnen stellen om dit soort problematiek in de toekomst te voorkomen. Met een, "het was een configuratie-dingetje" kom je echt niet meer weg. Blameless post mortem is de standaard.

[Narathan]

Ik ben QA tester/analist en ik ben het roerend met je eens. Vorige klus was voor financials en dat was een geoliede machine - toen hebben we in 9 maanden gedaan waar 2 jaar voor was uitgetrokken.

Maar nu werkt ik op een klus voor de overheid en ik snap wel waarom de projecten... "moeizaam" verlopen. We zijn nu een paar jaar over de deadline heen zal ik maar zeggen en dat heeft alles met het management te maken.

Heb nog nooit zo veel wissel van de wacht en uitstroom gezien als op dit project. En het is te merken aan de kwaliteit.

[Oyxl]

Bekend verhaal.

Ik kom met een analyse, daarbij zet ik kort puntsgewijs wat het probleem is, oorzaak, gevolg, randvoorwaarden etc, met daarbij context en onderbouwing.

Dan hoor ik drie weken niets en vervolgens komt viavia het verzoek of we nu eens goed kunnen uitleggen waarom x,y,z, maar wel beknopt.

Ik stuur de bullet points nogmaals, maar nu zonder context. Direct reactie terug, blijheid alom.

Als je beseft dat management bij overheid voornamelijk zo weinig mogelijk wil weten, dan kom je er wel. (En anders doet men letterlijk een TLDR).

[Reactie gewijzigd door Oyxl op 24 juli 2024 11:43]

[dasiro]

in a nutshell: overheden moeten geen rechtstreekse verantwoording afleggen en budget wordt eigenhandig opgeëist van burgers, terwijl schulden gewoon vooruit worden geschoven. Tegelijkertijd willen ze allemaal wel een vinger in de pap hebben om prestige én tegelijkertijd plausible deniability te hebben. kennis van zaken is vaak ook geen vereiste.

[oscar oscar]

Nou, in mijn ervaring helemaal niets te maken met ouderwets management, integendeel zelfs.

Management hoort hun teams te vertrouwen, en kent vaak geen zak van development. Als het team zegt dat het een config fout was in bepaalde condities en stappen ondernomen heeft zodat dit niet meer voorkomt moet dit voldoende zijn.

[Verwijderd]

Dat is inderdaad de goede insteek. Een tijdje terug bij een team gezeten die Agile wilden gebruiken. De scrum master was ooit een developer geweest en was daarna projectmanager over dat team geworden. Omdat hij deze stappen voorheen had gemaakt was hij soms zo gedetailleerd dat hij het beter zelf kon doen. Hij kauwde het voor in plaats van het coachen.

Management moet alleen helikopter view hebben en weten bij wie de moeten aankloppen die in depth is en het op kan lossen.

[sympa]

Maar het management moet genoeg weten om niet voor de gek gehouden te worden...

[Tjidde]

Daar zit de lijn. Zo min mogelijk informatie geven aan je manager waar hij of zij niet op zit te wachten. Maar wel genoeg dat hij vertrouwen kan hebben dat men eerlijk is.
Dit kan op meerdere manieren natuurlijk. Dit kan door soms juist wel wat dieper uit te leggen van dit en dit is wat er gebeurde. Of je interne rapporten voor je mededevs gewoon openbaar te stellen aan je manager(s)(of die hem snapt of niet maakt niet uit), maar met gewoon een summary van de probleem in een mail naar de manager(s).

Zolang het management geen vertrouwen heeft in haar teams zal er juist denk ik meer gelogen worden dan als ze het wel doen.

[sympa]

Ik heb gewerkt bij een bedrijf waar het management geloofde dat de IT-afdeling de hele IT opnieuw aan het bouwen was. Kon niet gedemonstreerd natuurlijk, want het was niet af.
De afloop was dat het het bedrijf werd overgenomen. En de inhoud van het datacenter kon de shredder in.
Over de kosten heb ik verschillende cijfers gehoord, maar het zal zeker boven de 10 miljoen geweest zijn.

[Yggdrasil]

Denk dat er intern ook wel echt in meer detail gesproken is, maar dat zal niet in de press-release terecht komen.

[ToolkiT]

blameless is sleutelwoord.. mensen maken fouten en als je een cultuur kweekt waar men dat ook toe durft te geven kom je snel bij de bron van het probleem.. anders is de menselijke aard om snel hun eigen fouten te verhullen om hun hagje te redden..

[sympa]

Yup, "X is foutgegaan want dat moet je laten testen en aftekenen". In plaats van "pietje waarom heb je dat toch gedaan".
In de luchtvaart en de zorg is dit al gebruikelijk.

[eborn]

En zelfs daar gaan nog 'regelmatig' dingen fout. Geen idee hoe vaak deze CDN er in de afgelopen jaren uitgelegen heeft, en hoeveel releases er zijn gedaan. Maar ik zou dat wel eens in relatie willen zien tot bijvoorbeeld de zorg. Van de luchtvaart heb ik (misschien ten onrechte) een iets hogere pet op. Ook omdat hier misschien minder mutaties plaatsvinden.

[sfc1971]

De zorg:

40.000 complicaties met schade
30.000 vermijdbare incidenten met schade
1.000 overlijdens door een incident

https://fondsslachtofferh...eken-medische-incidenten/

En er zijn hogere cijfers te vinden. Iedere dag 3 doden in Nederland alleen. Dan doet Fastly het oneindig beter.

[sympa]

En als er aangeklaagd wordt, dan heeft dat tot gevolg dat alleen strak het protocol gevolgd gaat worden.
Wat ook verkeerd uit kan pakken.
Dat is wat bedoeld wordt met "blameless". Iedereen gaan zitten, iets is fout gegaan, okee die beslissing van mij was niet juist. En hoe voorkomen we dat dan: cursus, iemand mee laten kijken, zeg het maar.
Maar niet een "schuldige" aanwijzen en dan denken dat het daarmee is opgelost.

[SED]

Als je naar de recente Boeing blunders op software ontwikkeling kijkt hoef je er niet zo'n hoge pet van op te hebben.

[sympa]

Het gaat om het melden van dingen die fout gaan. Een piloot kan anoniem melden dat een vliegtuig "raar" doet. Zonder dat ie bang hoeft te zijn voor zijn of haar job (oh dat is zeurende pietje weer die onze onderhoudskosten omhoogjaagt).
En als het onderhoud niet goed is, wordt de procedure aangepast. En wordt er niet gewezen naar henk die als laatste aan de schroefjes heeft gedaan en 'dus' de schuldige is.

[Reactie gewijzigd door sympa op 24 juli 2024 11:43]

[SED]

Dan heb je het over onderhoud en niet over software ontwikkeling.

[sympa]

Boeing heeft deze cultuur duidelijk niet (meer). Het was de piloot, het was de maatschappij die een optie niet had besteld, het was het land van de piloot, noem maar op.
Maar het was niet "oh jee dit mag echt niet gebeuren, we gaan het uiteraard oplossen".

[Sito]

Ik vind dat ze er juist open en transparant in zijn, in ieder geval in hun aanpak en hoe ze het in de toekomst gaan voorkomen. Het is toch niet nodig om te vermelden wat tot in detail het issue was. Feit is dat het blijkbaar een exotische configuratie is, omdat het bijna een maand heeft geduurd tot een klant het specifiek stukje configuratie heeft gebruikt vanaf het moment dat het gereleased is.

Qua communicatie kan menig bedrijf hier wat van leren. Als de Ziggo DNS bijvoorbeeld een paar uur down is hoor je er niks van, behalve een "het is opgelost!" Tweet.

[SunnieNL]

En eerlijk, meer hoef je ook niet te weten van Ziggo als consument.
Dit gaat over een veel groter probleem met hele grote klanten en sites erachter. Dit probleem was over de hele wereld, met allerlei apps, etc. te merken omdat er een grote cloud infrastructuurklant achter hangt. AWS had hier grote problemen mee en zelfs enkele diensten die wij met het bedrijf op Azure draaien klapten er uit.
Dan mag je wel met een wat grotere update komen dan alleen "het is opgelost". Die klanten willen weten "en hoe zorg je ervoor dat dit nooit maar dan ook nooit meer voor komt".

[amx]

Die klanten die op bloed uit zijn bedoel je
Ja, zakelijk gezien is Fastly aansprakelijk, en ja, als zijn een 100% uptime SLA aanbieden zijn ze financieel aansprakelijk (en is het einde Fastly vermoedelijk)
Zo niet, kun je op hoge poten gaan staan om je belangrijk te voelen of een rechtzaak beginnen maar daar houdt het op
Klantcommunicatie is geen onderdeel waar de klant inspraak op heeft, buiten de handelsrelatie aangaan of verbreken.

[Verwijderd]

Bedrijven die 100 procent uptime beloven in hun SLA zijn niet goed wijs in mijn ogen. Dat is in de praktijk gewoonweg niet te doen.

[NTS]

Content delivery en andere infrastructuur providers die 100% garanderen doen dat meestal door twee dingen slim in te richten:

1. Ze werken met meerdere locaties / verbindingen en garanderen dat er één werkt en sluiten alle externe issues uit van hun SLA, dus ze garanderen nooit dat alles altijd 100% online is.

2. Als ze het niet halen krijg je niet een unlimited schadevergoeding maar meestal service credits (gratis gebruik in de toekomst) in verhouding met hoe lang het niet werkte.

Dus ze weten bij #1 dat de kans heel klein is en bij #2 dat het ze niet al te veel kost.

[SunnieNL]

Dat hoeft niet te zijn dat klanten bloed willen zien of een vergoeding willen hebben. Zeker niet als het maar zo kort is als nu. Maar iets meer informatie dan "het is opgelost" verwachten dit soort klanten wel. Die willen een minimale informatie waar het probleem ongeveer lag en hoe je in de toekomst gaat voorkomen dat dit weer kan gebeuren. Je laat dan als bedrijf in ieder geval zien dat je er over nagedacht hebt.

Als AWS, Azure, Exchange Online of Office Online eruit klopt wil je als klant van Microsoft toch ook iets meer weten dan "he, het werkt weer".

[Reactie gewijzigd door SunnieNL op 24 juli 2024 11:43]

[amx]

Ik heb net de verklaring gelezen. Het is een managementsamenvatting waarin ze met de billen bloot gaan. Het ziet er daarnaast naar uit dat het om een eenzijdige configuratiefout gaat waar klanten niks aan konden doen en waar als Fastly de fout niet herhaalt, klanten niks aan hoeven te doen.. Ook hebben ze hun software gezien de link onderin de persverklaring grotendeels zelf ontwikkeld en is niet in te schatten hoeveel informatie ze over hun eigen code vrijgeven door daar verder op in te gaan. Ik denk gezien de manier hoe het geschreven is, dat het een menselijke fout is geweest, sugar coating maakt het dan niet mooier en leidt vaak tot meer vragen. "He, het werkt" weer is niet de strekking van de persverklaring, iets waar in het gedeelte Where do we go from here op in wordt gegaan.

[svane]

Volgens mij is Fastly alleen maar aansprakelijk voor wat ze zelf in de SLA hebben gezet.

In dit geval lijkt dat te gaan om 10% korting in de vorm van credits. Zou makkelijk te overleven moeten zijn voor ze

[mrperson1234]

Ze hoeven toch het precieze ook niet uit te leggen? Dat zal denk ik diep in hun code gaan wat niet opensource is. Dus ja, dan is een opmerking van we hebben een aanpassing gedaan waardoor dit niet meer zal voorkomen toch genoeg zijn?

Ik zou ook graag meer willen weten. Maar een gemiddelde persoon snapt het niet als je met allemaal termen gaat gooien. Dus het zou leuk zijn als ze er een dev blog bericht over zouden maken. Maar ze zijn het niet verplicht.

[wica]

Jij en ik willen misschien in detail weten wat er gebeurd is. Maar de meeste klanten boeit het allen, wat ga je doen om dit te voorkomen.
En laten we eerlijk zijn dat is ook wel belangrijker dat de bug zelf

[Verwijderd]

Oh dit doe ik ook dagelijks bij klanten als er iets niet meer werkte en ik heb het opgelost. Ook al is het niet mijn schuld geweest, hoe meer info ik geef hoe meer vragen ze gaan stellen, geen tijd voor.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 11:43]

[Frame164]

Dat is dan een developer met hele goede communicatie vaardigheden. Intern met z'n collega's mag hij/zij op de details in gaan, maar naar buiten toe is dit bericht goed genoeg. Na deze zin haken de meeste mensen af als je dan doorgaat met vertellen wat er fout is gegaan.

[sebasmac]

Is fastly van amazon of maken ze express geen gebruik van hun eigen AWS?

[lenwar]

Fastly is een eigen bedrijf. (Fastly Inc)

Goede kans dat Fastly hun diensten off the shelf kunnen aanbieden en dat Amazon die dienst intern niet heeft. Ze zouden het natuurlijk zelf kunnen bouwen, maar als een ander er in is gespecialiseerd, dan kan je er voor kiezen dat te gebruiken natuurlijk.

Overigens is er ook een goede kans dat de Fastly diensten deels op AWS draaien
https://www.fastly.com/partners/featured

[BugBoy]

AWS heeft zoveel resources in huis dat het mij ook enorm heeft verbaasd dat ze blijkbaar deels gebruik maken van een CDN buiten AWS. Maar het kan natuurlijk ook een andere ingekochte dienst zijn die ze gebruiken in hun eCommerce platform die via Fastly loopt. Maar geloof maar niet dat Amazon hier iets over vrijgeeft. Daar is transparantie helemaal ver te zoeken...

[sympa]

Misschien zit Fastly wel dichterbij de gebruikers.

[lenwar]

Nou ja. Amazon had ook last van de storing, dus blijkbaar nemen ze zelf ook een dienst van Fastly af. Buiten dat. Je kan natuurlijk wel walgelijke hoeveelheden technische capaciteit hebben, maar op een gegeven moment gaat het natuurlijk ook uitmaken of je die capaciteit efficient kan gebruiken. Meer (virtueel) ijzer er tegenaan gooien is natuurlijk altijd een 'oplossing', maar vaak kan je softwarematig ook heel veel afvangen, wat dan weer veel goedkoper/efficienter kan zijn.

Fastly heeft ook bijvoorbeeld DDOS mitigation in hun portfolio. Misschien dat zij dit primair doen voor Amazon? Dat is toch een vak apart. Meer dan alleen maar 'meer ijzer'

[:murb:]

Fastly is geen onderdeel van Amazon, maar terechte vraag waarom Amazon.com niet gebruikt maakt van diens eigen CloudFront. Wellicht is Fastly toch net wat sneller, goedkoper of beter waardoor ze meer verkopen. Komt wel vaker voor bij grotere organisaties, maar een goede reclame voor AWS CloudFront is het niet.

Update: Amazon.com maakte ooit gebruik van z'n eigen AWS (Amazon Web Services) CloudFront dienst, maar is in 2020 geswitched naar Fastly, dat gewoon beter bij hun behoeftes paste dan CloudFront.

[Reactie gewijzigd door :murb: op 24 juli 2024 11:43]

[ToolkiT]

Dit zat ik me ook al te bedenken.. waarom een derde partij betalen als je zelf een CDN platform hebt..

Blijkbaar is Amazon.com meer gescheiden van AWS dan we vermoeden..

Maar qua marketing is dit wel een deuk voor Cloudfront inderdaad..

[parsa2020]

Vergeet niet dat het natuurlijk wel onder hetzelfde moederbedrijf valt, maar het waarschijnlijk opereert als een los bedrijf. Het is niet ongewoon voor grote bedrijven dat een dienst een andere dienst 'afneemt' van zichzelf, waarbij ze dus ook echt als klant van die andere dienst worden gezien. Dat maakt het namelijk ook makkelijker voor zo'n bedrijf om een overzicht van de kosten te houden, want ook intern gebruik van diensten brengt natuurlijk kosten met zich mee (zoals gemiste inkomsten bijv., maar genoeg andere opties).

[Aetje]

Dat of het is een gevolg van een overname. Amazon neemt een hoster over die Fastly gebruikt, analyse wordt gedaan of naar de eigen dienst overschakelen de kosten van de transitie waard is. Conclusie erop is "nee" en dan heeft Amazon webhosting CDN diensten bij een concurrent.

[Frame164]

Het kan ook nog geografisch zijn. AWS is nog niet overal dichtbij de eindgebruiker. Fastly kan wellicht de gaten opvullen.

[don_jorg]

Ik heb nog nooit de management gedaan van een CDN (mijn niveau ligt op 'Synology package installeren --> ik heb een interne website'), maar wellicht dat mensen hier me deze tekst kunnen uitleggen:

De problemen ontstonden volgens Fastly rond 11.47 uur Nederlandse tijd. Het probleem werd 40 minuten later ontdekt

Even los van problemen/probleem (zijn het er nu meer of was het er maar één?): bij een dergelijke bedrijfskritische installatie, waarom duurt het 40 minuten voordat ze het merken? Misschien heb ik de tekst verkeerd begrepen en begon om 11:47 een sneeuwbaleffect waardoor het steeds erger werd. Als dat niet zo is, zouden toch direct overal rode lampen moeten gaan ronddraaien?

[ToolkiT]

Ik vermoed dat het een replicatie effect is..
Kijk maar eens naar DNS wijzegingen, dat duurt ook altijd even voordat het global uitgerold is.. ik vermoed dat bij CDN je een zelfde effect hebt.. de cache moet namelijk eerst naar alle edge locations gestuurd worden etc.. en routings aangepast etc..

[SunnieNL]

Het probleem werd niet 40 minuten later ontdekt. het probleem startte om 11.47, om 11.48 had het systeem al ontdekt dat er iets mis was en alarm geslagen. Om 11.58 ging er al een update naar de website dat er een probleem bekend was.
Om 12.27 was de oorzaak van het probleem ontdekt en 10 minuten later was de workaround actief en kwamen services terug online.

Het onderzoek naar de oorzaak duurde dus 40 minuten. Het probleem opmerken 1 minuut.

[Reactie gewijzigd door SunnieNL op 24 juli 2024 11:43]

[don_jorg]

Dat klinkt al een stuk logischer, ja. Dank je wel voor de toelichting (ook @Aetje !)

[Aetje]

Ik denk dat dit wat onhandig verwoord is en dat men bedoeld "de oorzaak van de storing werd 40 minuten later ontdekt".

[Wasp]

Er is dus hoogstwaarschijnlijk één persoon geweest op deze wereld die zonder dat 'ie het in de gaten had, het halve internet heeft platgelegd.

[Xieoxer]

Wij hebben in het verleden Faslty gebruikt, en ik moet zeggen dat het ideaal is voor programmeurs. Je kunt als content eigenaar programmeren hoe jouw data wordt geserveerd aan het internet. De configuraties zijn eindeloos.

Edit: aangepast naar geserveerd

[Reactie gewijzigd door Xieoxer op 24 juli 2024 11:43]

[dasiro]

ik hoop dat je "geserveerd" bedoelt, anders heb je wel héél veel rechten

[kdekker]

Een user error die een bug triggert, maakt m.i. die gebruiker nog niet schuldig. Code is nooit bug free, maar de impact van fouten is voor een 'normale eindgebruiker' niet te overzien. Ok, er zijn ook zat gebruikers die op de randen van het spectrum begeven en dan zeggen 'huh hij doet het niet'. 100% hufterproef programmeren is wellicht een loffelijk streven, maar mogelijk ook kostprijsopdrijvend. Perfectie voor een 'prikkie' bestaat niet . Of meer: perfectie is niet bereikbaar in deze wereld, en zou de prijs navenant hoog maken.

[Reactie gewijzigd door kdekker op 24 juli 2024 11:43]

[kielstra]

Ze geven toch aan dat ze zelf die bug geïntroduceerd hebben? Ze geven de klanten niet de schuld, ze zeggen alleen dat het pas bekend werd toen een klant een bepaalde configuratie instelde.

[WendelV]

Dit toont een groot zwaktepunt voor het huidige internet. Daarnaast ook een privacy issue, die grote CDNs kunnen je volgen over het gros van de websites die je bezoekt.

[bartdiaz]

Klopt, interessante bijvangst, al die informatie.. leuke mogelijke extra inkomstenbron voor dit soort bedrijven.. En wat dacht je van DNS? Iedereen die klakkeloos Google's DNS gebruikt.. wát een informatie geef je weg.. maargoed, dat is offtopic

[Frame164]

Maar het is ook de kracht. Door CDN's kan veel data efficient en economisch beschikbaar worden gemaakt. Zonder CDN heb je veel meer netwerkcapaciteit nodig en moet iedere contentpartij fors investeren in z'n eigen platform. Er wordt dan ongelofelijk veel onnodige capaciteit gebruikt. Al dat geld kan beter worden besteed aan het doel (content maken).

Als iedereen het zelf zou doen zou je een uitgeverij krijgen die z'n eigen boeken drukt, en door het inrichten van een drukkerij geen geld meer heeft om schrijvers boeken te laten schrijven.

[Gravit0n]

Rollback 0

[bwerg]

De bug zat er al een maand in, dus een rollback zal niet zo simpel zijn.

[Wraldpyk]

Plus, in de software wereld is een rollback altijd een final resort (of in ieder geval, zou moeten zijn). Eerst proberen de bug op te lossen zonder rollback, want de update die het veroorzaakt heeft, heeft altijd meer dingen er in zitten als die ene bug, en kans is groot dat ze daarmee weer andere bugs her-introduceren.

[Frame164]

Rollback heeft alleen zin bij statische systemen. Zodra je met dynamische data hebt te maken, en een CDN is bij uitstek een ding dat met dynamische data werkt, heeft een rollback geen zin. Dan ga je wijzigingen verliezen. Je moet gewoon door op het moment dat je bent begonnen.

[Mars Warrior]

Wat het dus precies was wordt dus nu niet aangegeven.

Het enige dat ik gisteren kon zien in de Chrome Inspector is dat bijna alle plaatjes en CSS een "CORS" error gaven, en dus niet geladen werden door Chrome.

[walkstyle]

Ook Github Pages was down.

Vraag me trouwens af of Fastly iets gebruikt als BugSnag/Sentry (Error Monitoring) hier kun je erg goed al problemen snel detecteren.

[Jorgen]

Ik heb het idee dat deze problemen er al eerder dan 11:47 waren. Twitter had er in elk geval ook veel last van. Mijn ingeplande tweet (dagelijks 10u NL tijd) was wel uit de wachtrij verdwenen, maar niet gepost