Slack ondervindt wereldwijd een storing

Messagingdienst Slack heeft maandagmiddag last van een storing. Gebruikers van de dienst kunnen geen of slechts sporadisch berichten met elkaar uitwisselen. De oorzaak van de storing is onbekend.

Slack bevestigt met een storing te maken te hebben, zonder details over de oorzaak te geven of aan te geven wanneer deze verholpen zou moeten zijn. De problemen betreffen messaging en verbindingen en lijken zich wereldwijd voor te doen.

De storing vindt plaats op een moment dat veel Amerikaanse werknemers weer aan de slag gaan na het weekend en nieuwjaarsdag. Slack is met name populair als zakelijk chatplatform. Berichten die gebruikers elkaar sturen, komen niet of pas laat aan en gebruikers hebben moeite om verbindingen te maken met het platform.

Reacties (52)

[killercow]

mooi hoor,die centralisatie

IRC vloog er ook wel eens (voor een stukje) uit natuurlijk, maar Wereldwijde storingen kunnen echt alleen als er maar 1 partij is die het platform beheerd.

[The Realone]

Maar het maakt mij, even bot gezegd, geen klap uit dat andere gebruikers op deze planeet er last van hebben. Als mijn "deel" eruit ligt heb ik er last van. Of dat nu om mijn lokale servers/private cloud gaat, mijn cloud region of globaal, het effect voor mij is hetzelfde. En dat is voor IRC niet anders.

[killercow]

Het grote veschil is dat je er dan zelf iets aan kunt doen (zelf hosten bijvoorbeeld), of dat je een indicatie krijgt over wat er mis is en hoe lang het gaat duren voordat het weer opgelost is.

In het ergste geval spring je met je team even naar een andere irc-server toe en kun je verder babbelen. Kan me zo voorstellen dat je manager dat een prima keuze zou vinden als die bestond.

Of je typt door op de tweakers.net irc server.
irc://irc.tweakers.net/#tweakers.net

[Reactie gewijzigd door killercow op 23 juli 2024 09:45]

[The Realone]

Als je het zelf host en het gaat plat, lig je ook plat. Er "zelf iets aan kunnen doen" is niets anders dan de juiste specialisten erop los laten die het voor jou oplossen, of dat nu het interne IT team, jouw IT leverancier of Slack zelf is. Daar komt bij dat er veel meer kennis om dit op te lossen bij Slack zelf zit, dus je hoeft niet te denken dat je het zelf per se sneller kunt.

Overigens denk ik niet dat mijn maar manager het leuk zou vinden als ik even uitwijk naar een random IRC server voor onze bedrijfscommunicatie.

[casberrypi]

Het allerbeste van iets self-hosten is dat je verstand blijft houden van een voor jouw organisatie kritisch stuk infrastructuur. Al was het alleen maar een Docker containertje met Mattermost up-to-date houden. Echt veel tijd kost het niet, maar je houdt als organisatie wel je eigen infrastructuur in beeld. Natuurlijk moet je dat dan dus wel bijhouden, en dat kost tijd en is dus niet gratis nee.

Ik zou dat zeker niet voor alles doen. Wij hebben niet onze eigen telefooncentrale of ticketsysteem in beheer, maar sommige diensten zoals Mattermost kun je wél eenvoudig zelf hosten.

[supersnathan94]

Het allerbeste van iets self-hosten is dat je verstand blijft houden van een voor jouw organisatie kritisch stuk infrastructuur.

Sure. Totdat Pietje het bedrijf verlaat na 10 jaar en Pietje niks gedocumenteerd heeft.

Punt van dit soort dingen zelf doen is niet dat je een hogere uptime kunt garanderen (want dat kun je niet), maar bijvoorbeeld dat bedrijfsdata inhouse blijft en je bijvoorbeeld geen wachtwoorden in chats hebt op een amerikaanse server.

[K-aroq]

Maar je snapt ook wel dat dit voor de meeste bedrijven helemaal geen optie is. Als je dit echt serieus wilt doen heb je een IT team nodig dat groter is dan de meeste bedrijven zijn. Het gaat immers om alle applicaties die een bedrijf gebruikt.

[raptorix]

Ja dat zelf hosten kennen we wel, van die bijdehandjes die roepen: Nee joh, dat kun je zelf doen. En er dan later achter komen dat de beheerder vergeten was het image te patchen, dat het toch met iets te veel rechten in het netwerk hing, en hoe dit dan toch kon gebeuren. Mijn ervaring is dat hoe meer een bedrijf iets zelf inhouse neemt, hoe minder volwassen de organisatie is, uitzondering zijn weer de zeer volwassen bedrijven waarbij het weer gaat lonen om het in eigen beheer te nemen, maar dit zijn mijn inziens uitzonderingen, veruit de meeste bedrijven kunnen het beste gewoon PAAS of SAAS diensten afnemen.

[GlowMouse]

Je stelt dat er 'veel meer kennis om dit op te lossen bij Slack zelf zit', maar dat is volkomen uit de lucht gegrepen. Ja het is hun core business, maar bij zo'n storing gaat het om de mensen die het systeem van haver tot gort kennen, ofwel hoe groot het verloop is van werknemers en of kwaliteit wordt behouden. Dat zijn dingen waar je geen enkel zicht op hebt bij een extern bedrijf. Intern heb je volledige controle over je werknemers en hun expertise.

Intern krijg je ook een beter beeld wat er aan de hand is. We zijn nu 2,5 uur verder, en meer dan 'we nemen dit serieus en zijn ermee bezig' is er niet gecommuniceerd. Dat is toch wat mager voor een bedrijf waar je elke maand een middenklasser aan betaalt.

De SLA is trouwens filterdun. Een uptimegarantie van 99.99% op kwartaalbasis (haha), en nauwelijks gevolgen als dat niet wordt gehaald. Voor elke drie kwartier downtime krijg je 1% korting op je maandelijks factuur, teehee.

[Reactie gewijzigd door GlowMouse op 23 juli 2024 09:45]

[The Realone]

Hoezo is dat uit de lucht gegrepen? Zij ontwikkelen het product en hebben dus meer kennis van het platform dan een klant ooit zal hebben. Met een outage als deze mag je ook gerust aannemen dat daar al hun kennis en kunde bovenop zit. Als jij denkt dat dat anders is zit je echt goed mis en heb je blijkbaar weinig ervaring met hoe dit bij bedrijven in elkaar steekt.

Je noemt allerlei redenen waarom die kennis er niet meer zou zijn maar gaat er vervolgens volledig aan voorbij dat dit bij een gemiddelde organisatie met een IT afdeling niet zou kunnen gebeuren. Juist daar is het verloop van kennis veel groter simpelweg omdat het niet de core-business is. Want waarom moet ik een de software tot op source code niveau kennen? Dat is, naast dat het schier onmogelijk is, ook totaal niet relevant en zal dus ook niet gebeuren. Daar zijn uitzonderingen op, maar die zijn enkel weggelegd voor de zeer specialitische toepassingen of organisaties met zeer veel resources. Via mijn vorige werkgever werkte ik bij een productiebedrijf en hoewel daar aardig wat kennis van het PLM pakket binnen zat werd bij grote of complexe storingen nog altijd de hulp van de leverancier van het pakket ingeroepen.

Niks zo vervelend als moeten wachten tot een probleem opgelost is, maar de #1 prio van Slack is het oplossen van het probleem, de RCA komt later.

[NielsFL]

Zelf heb ik RocketChat of MatterMost ook in 10 minuten weer draaien. Desnoods op een nieuwe virtuele machine en een vers domeinnaampje. Maar tegelijkertijd snap ik ook wel dat dat niet voor iedereen zo werkt.

Je eerste argument was overigens beter: centralisatie is het grote gevaar. Zelf of niet zelf beheren/hosten is minder belangrijk. Het liefst heb je iets wat je bij verschillende aanbieders kunt afnemen en wat onderling communiceert.

E-mail is daar nog steeds het beste voorbeeld van. Wat dat betreft is het jammer dat iets als Matrix niet van de grond komt. Aan de server kant is dat inmiddels best OK, maar de client apps zijn ronduit verschrikkelijk.

[MartenBE]

Niet van de grond is een sterke uitspraak: samenwerking met Franse en Duitse overheden, samenwerking met Duitse scholen, wordt gebruikt als officieel kanaal voor online conferenties zoals HOPE en FOSDEM, en wordt meer en meer ingezet bij opensource ter vervanging van IRC zoals bij Mozilla, KDE en diverse andere projecten. Ook zijn er meer en meer clients, dus je kan er zelf een uitkiezen: van de default Element, tot de commandline Weechat, tot de nieuwe ingebouwde KDE client. Ik ben wel overtuigd alvast dat er toekomst in zit

[Douweegbertje]

Ik word altijd een beetje moedeloos van dit soort discussies. Al is het maar cloud vs on-prem, 'as a service' vs self hosted.

Om Johan te quoten: elk voordeel heeft zijn nadeel.

Uiteindelijk komt het erop neer dat je op basis van allerlei argumenten en input hopelijk een weloverwogen keuze maakt in welke oplossing je kiest. Dat je weet wat de pro's en con's zijn. Want je hebt het nu even over zelf hosten. Echter zijn er nog wel 100 andere argumenten te verzinnen om het zelf te doen. Net zo goed er weer 100 argumenten zijn om het af te nemen. Nutteloze discussie om dit allemaal te gaan benoemen omdat dit per persoon, doel, bedrijf, etc. verschillend is, in wat men als juiste keuze acht.

Echter lukraak bij elk "issue" roepen van:
(bij on-prem): heuahau zaten ze maar in de cloud
of
(bij cloud): haeuahaue zaten ze maar on-prem..

begint echt vervelend te worden.

[killercow]

Tweakers.net is een tech site. Als we al niet meer de voor en nadelen van bepaalde technische oplossingen en keuzen mogen Be-discussieren, wat doen we dan hier.
Mischien is een site zonder comment-sectie is voor je?

Also, je hoeft mensen niet meteen een spraakgebrek te geven als je ze na wilt doen, dat is echt bijzonder kansloos.

[Reactie gewijzigd door killercow op 23 juli 2024 09:45]

[The Realone]

Een beetje flauw, wat jij begint met de opmerking "mooi hoor,die centralisatie" en doet net alsof zelf hosten altijd superieur is aan cloud oplossingen. Blijkbaar ben je een groot IRC fan en dat mag, maar IRC is in enorm veel gevallen inferieur aan oplossingen als Teams en Slack. Daarnaast zie ik het binnen veruit het grootste deel van de bedrijven geen meerwaarde om dit soort oplossingen zelf te hosten. Sterker nog, met de kennis, tijd en de centen wat dat kost is het verre van verstandig. Ik werk voor een universiteit met 42k studenten/medewerkers en we zijn niet vies van zaken zelf hosten, maar we gebruiken gewoon Slack, Teams en Google Meet voor communicatie.

[GeroldM]

Hier gaan oude, afgeschreven machines het depot in. Maar in het verleden is er al vaker een machine eruit geklapt vanwege een stroomstoring. Het grid hier in Paraguay (Zuid-Amerika) is zeker in dit deel niet zo geweldig.

Maar dan was het een kwestie van naar het depot lopen, machine uit het rek plukken, openschroeven, dan de geklapte machine uit het rek plukken, openschroeven, de hard disk eruithalen, in de andere machine plaatsen, dichtschroeven en deze in het server rek terug te plaatsen. Opstarten en daar gaan we weer.

Mail en web server (inclusief NextCloud) weer terug online binnen 10 tot 15 minuten.

Werkt uitstekend met Linux machines (zonder GUI), zelfs als er van Intel naar AMD of andersom word gewisseld. Doen nu al 12 jaar met dezelfde mail server (1 keer een drive moeten clonen, wat zo'n 45 minuten in beslag nam), 4 keer van van computer gewisseld. Werkt als een t.et.

Dat kost niet al teveel aan kennis of tijd. Aan hardware gerelateerde down-time over een periode van 12 jaar is zo'n 2 uur geweest. Down-time door gebrek aan stroom, dat is veel meer uren geweest over die 12 jaar. Daar viel weinig aan te doen (en nee, met 2 uitgebrande en 6 andere kapotte UPSsen ben ik niet meer zo happig op een UPS als noodvoorziening).

Ook onderhoud/updaten van zulke Linux servers valt reuze mee, kost me mischien 1 uur per week voor alle 5 Linux servers die ik hier heb draaien. Ja, het is tijd en kost daardoor geld, maar om dat nou uit te besteden? Voor mijn opzet werkt de huidige methode wonderwel goed.

Of dat ook zo vertaald naar een grotere omgeving zoals de Uni waar je voor werkt, dat is inderdaad maar de vraag. Maar de truuk van het uitwisselen van harde schijven (met GUI-loze Linux) in machines, werkt echt en is minder problematisch dan met Windows machines. Verwacht echter ook dat een Uni over een groter en beter toegerust datacenter beschikt, dus zou het in principe wel tot de mogelijkheden kunnen behoren. Zeker qua kennis en tijd.

Blind staren op Cloud is makkelijker en/of goedkoper. Met het laatste kom je al gauw bedrogen uit, maar makkelijker is het wel. Qua bedrijfszekerheid zal on-premise/Cloud elkaar niet zo heel veel ontlopen. Heb je de kennis/expertise al in huis (op een Uni verwacht ik dat er toch genoeg mensen/studenten rondlopen met verstand van zaken om het on-premise verhaal in de lucht te kunnen houden), lijkt het mij toch altijd verstandiger om goed naar kosten/baten van beide oplossingen te kijken. Verstandiger dan meteen maar roepen dat alles de Cloud in moet.

Met Cloud betaal je en geef je kennis op (langere termijn), met on-premise betaal je en win je aan kennis (op langere termijn). Het mag dan wel geen core-business voor je zijn, als er kosten worden gemaakt en je krijgt er geen kennis voor terug, dan is misschien geen weggegooid geld, maar of je je geld optimaal hebt besteed...

Cloud is voor heel veel zaken wel interessant, maar zeker niet voor alles. In mijn optiek is het hele Cloud hosanna niet meer dan dat.

[The Realone]

Om te beginnen zal je mij echt niet horen zeggen dat de cloud een oplossing voor alles is, in ieder geval de komende decennia nog niet. Het is een afweging die je per dienst moet maken. Maar mijn reacties waren gericht op mensen die deden alsof het pertinent beter is om dit soort zaken in zelf te hosten en dat dit het grote probleem van de cloud is, wat dus gewoon onzin is.
Om die vergelijking met de uni waar ik voor werk maar weer te maken, ik werk in een IT team met een specifieke taak waar onze afdeling zijn brood mee verdient. Een andere IT afdeling binnen de uni is verantwoordelijk voor de SCCM infra, daar waren onlangs problemen mee. Wij moesten wachten totdat zij dit opgelost hadden, dat was vervelend maar wel de realiteit. Het is hun infra, zij hebben daar een team zitten met uitgebreide SCCM kennis dus wie beter dan hun om dit op te lossen.

Het alternatief is zelf een SCCM instance hosten met alle toeters en bellen. Dat kost enorme bakken met tijd en geld om het wiel opnieuw uit te vinden. Dan moet je dan ook nog eens spenderen aan meerdere medewerkers binnen ons team, want wat als ik op vakantie ben of vertrek. Vervolgens heb je er onderhoud aan, moet je je kennis op pijl houden en altijd klaar staan om problemen op te lossen. Allemaal centen en uren die wij beter kunnen besteden aan onze core business. Onze core business is onder andere een specifieke dienst waar wij veel vanaf weten, waar 2 of 3 software oplossingen centraal staan. Nu hadden wij laatst problemen met het upgraden van 1 van die pakketten, dus waar gingen wij naartoe? Juist, de leverancier en ontwikkelaar van dit pakket.

[Picaroon]

Om Johan te quoten: elk voordeel heeft zijn nadeel.

Je bedoelt: “elk nadeel heb z’n voordeel”. Een groot verschil als je het mij vraagt.

[reneflo]

Ander verschil is dat je er ook iets aan moet doen. Nu Slack eruit ligt switchen we gewoon even naar Teams, mail of wat dan ook en werken we weer door (of we kijken even op tweakers.net). Ligt je eigen hosted versie eruit dan zal die hoogstwaarschijnlijk niet vanzelf weer na enige tijd beschikbaar komen.

[holoduke51]

Het gemak wat je krijgt met slack is zoveel meer waard dan een half bakken IRC oplossing. Zelfs een downtime maakt dat niet anders.

[Christoxz]

Ja maar dan ligt alleen jou IRC er uit, en nu bij iedereen zijn Slack.

[The Realone]

Dat is precies mijn punt, wat is voor jou het verschil? Als het enkel voor jou eruit ligt (en met jou is dat dan vaak minimaal 1 gehele organisatie) dan kun je niet communiceren met anderen. Ligt het er wereldwijd uit dan....kun je niet communiceren met anderen.

Overigens, mijn Slack werkt prima, ik gebruik het al de hele ochtend zonder problemen, maar andere in mijn team hebben last van haperende berichten.

[Christoxz]

Vrij weinig, dat klopt, maar nu liggen er duizenden bedrijven stil, ipv 1.
Vaak is dat enigszins snel opgelost, maar wat als dat niet zo is? Dan moeten ineens heel veel bedrijven een alternatief zoeken.

[The Realone]

Klopt, allemaal een probleem op individueel niveau. Het is dan pijnlijk voor Slack dat er veel klanten last van hebben, maar vanuit het perspectief van de klant maakt het helemaal niks uit.
Als ik zelf wat servers draait met mijn eigen communicatietool en dat gaat plat, moet ik het ook zelf oplossen.

[Christoxz]

Klopt, maar denken we ook aan de klanten van de bedrijven die Slack gebruiken?
Tuurlijk hebben deze bedrijven Slack niet persee nodig om hun diensten te leveren, maar om alles (efficient) draaiende te houden is communicatie ook van belang.(En/of toegang tot oude gesprekken, bestanden, polls en whatever er nog meer kan met Slack).

Al met al heb je een punt maar de centralisatie is ook wel zorgelijk.

[NielsFL]

Niet helemaal waar natuurlijk als je met IRC vergelijkt. Gaat jouw IRC server down dan log je in op een andere IRC server die tot hetzelfde IRC netwerk toegang geeft en je bent er weer.

(Dat gezegd hebbende vind ik IRC geen goed alternatief voor Slack.)

[klakkie.57th]

Punt blijft dat de uptime garanties van veel saas producten gewoon slecht zijn en de vergoedingen gaan nauwelijks ergens over.

Hoger management gelooft nog al te vaak de BS van bigtech. “Als u problemen heeft, dan heeft de halve wereld problemen en gaan we er zeker sneller achteraan dan u dat zelf kan”

Totale onzin natuurlijk, want we deden het al zelf de voorbije 20 jaar zonder noemenswaardige incidenten.
Toen ik 20 jaar geleden een panne had aan de computer die vrachtwagens moest laden, stond de bedrijfsdirecteur gewoon achter mij en zei hij dat hij iedere 5min 100.000BF verlies maakte. Die man is pas weggegaan toen ik het probleen had opgelost ...
na zo’n dag had je enige trots dat je wat had kunnen doen aan die ellende, nu kun je in het beste geval een ticket openen


Ah those were the days

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 09:45]

[The Realone]

Tja, dan moet je maar zorgen dat je daar vooraf over ingelicht bent voordat je de keuze maakt voor een SaaS dienst. Afhankelijk van de dienst en de organisatie kan enkele uren downtime per jaar echt geen kwaad en wordt dat vaak voor lief genomen. Als je het zelf beter en/of goedkoper kan moet je het natuurlijk zeker doen, maar het fabeltje dat dit altijd het geval is blijft hardkennig.

Leuke anekdote over de vrachtwagens natuurlijk, maar ook die vergelijking loopt mank. Dat je nu alleen een ticket in kan sturen wil niet zeggen dat er niet aan gewerkt wordt en dat wil al helemaal niet zeggen dat je hetzelfde probleem op je on-prem omgeving wel snel opgelost had. Overigens, als het elke 5 minuten 100k BF kostte was het het wel waard geweest om daar enige redundantie in te bouwen, niet? Datzelfde zou je tegenwoordig ook doen met een dergelijk kritisch systeem. Dat zet je niet in de cloud tenzij je failover situatie hebt

[Cergorach]

Maar ook hier maakt het niet uit of of het er bij alle bedrijven uit ligt. Uptime per bedrijf zal hetzelfde zijn of het nu verdeeld is over een jaar of allemaal te gelijkertijd. Het grote verschil is dat de downtime van Slack waarschijnlijk korter zal zijn dan die oplossingen die bij individuele bedrijven draaien. Het is immers de corebusiness van Slack om een irc kloon te verkopen en bij al die losse bedrijven is het slechts een tool dat ergens op een servertje draait.

Juist de 'kracht' van dit soort 'cloud' applicaties is dat iedereen bezig is met zijn of haar core business ipv. tig applicaties draaiende te houden.

[wica]

Bij IRC kies je een andere server in het zelfde netwerk en je kan weer verder.
Bij Slack is het afwachten...

[Cergorach]

Als het issue puur de IRC server zelf is en niet een ander issue, wat alle IRC servers beinvloed.

[killercow]

Hoe zou dat moeten werken dan? Er zijn tientallen verschillende implementaties van de server, en honderden verschillende clients. Dus los van een bjizonder goed verborgen gebleven protocol issue (of een groter internet probleem wat dan weer niets met irc van doen heeft) zie ik niet hoe dat zo zou moeten kunnen.

[Shadow771]

Aaaaahhh.. IRC... Goeie ouwe tijd voor mij (het bestaat nog steeds natuurlijk) ...

De grootste 'IRC'-storing dat je vrijwel kon hebben was een 'netsplit' tussen servers die een netwerk vormen waar veel users op zaten. Altijd leuk om dan die vloedgolf aan *** has Quit te zien.

[killercow]

Ik denk dat IRC gebruik niet veel kleiner is als toen. Echter zijn er nu gewoon meer internet gebruikers, en dus procentueel gezien is irc gekrompen.

Tenzij je alle stiekeme irc gebruikers ook meerekent, dan is het wel gedaald: msn was ook irc, allerlei web-chats (tmf), en natuurlijk slack zelf draaiden allemaal netjes op het irc protocol tot "feature creep" / "walled gardens" belangrijk en haalbaar werden voor de achterliggende bedrijven.

[MikeN]

Mwah, het is wel flink geslonken hoor.

Zie bijv.:

IRCnet, van 136k users op de piek naar 25k nu: https://netsplit.de/networks/statistics.php?net=IRCnet
Quakenet, van 242k naar 11k: https://netsplit.de/networks/statistics.php?net=QuakeNet

Eigenlijk alleen Freenode heeft door z'n open source user base de aantallen redelijk behouden: https://netsplit.de/networks/statistics.php?net=freenode

[Patriot]

Draait de chat van Twitch ook niet op IRC? Dan heb je het over 3,8 miljoen gebruikers op dit moment (er even vlug van uitgaande dat het aantal mensen dat de chat helemaal uitzet te verwaarlozen is).

[nickyhaan]

IRC had zeker ook last van storingen net doordat er veel mensen eigen servers op zette -> https://en.wikipedia.org/wiki/EFnet

[Risce]

Erg vervelend voor Salesforce, die een vrijwel vlekkeloos platform net gekocht heeft en meteen een vlekje kan wegpoetsen. Maar goed, paar weken terug waren alle Google services ook down en kort daarvoor waren er ook bij AWS grote problemen.

Goed om even stil te staan bij kwetsbare processen in je bedrijf en alternatieve workflows (bv. 'gewoon even bellen')

[robhuijben]

Wij gebruiken zowel Slack als Microsoft Teams voor de communicatie binnen onze organisatie, maar ik moet zeggen dat Slack toch vaker met storingen en instabiele verbinding te kampen heeft dan Microsoft Teams. Overigens heeft Salesforce Slack inderdaad gekocht, maar is die overname nog niet rond en zeker nog niet geïntegreerd, dus voor dat zover is heeft Slack nog e.e.a om weg te poetsen.

[heuvelmans]

Wij hebben Teams als onderdeel van ons Office E3 pakket en gebruiken dit al vaker voor telefonie/video meetings. Dat je er ook in kan chatten is mooi meegenomen en nu een mooie achtervang.

Maar geen een tool kan je 100% up houden, er zijn altijd wel wat problemen.

[geeMc]

Problemen horen er ook gewoon bij, maar bij Slack is het het laatste jaar wel erg frequent. Een dergelijke achtervang is natuurlijk handig en mooi als je een relatief klein bedrijf hebt, maar is bij een enterprise natuurlijk niet meer te doen. Niet om praktische redenen, maar ook niet om procedurele redenen. Voor bepaalde plans betaal je ze royaal, dan mag je ook wat verwachten. Het is niet voor niets dat outages ze afgelopen jaar ruim 8 miljoen dollar hebben gekost en ze hun SLA voorwaarden in hun eigen voordeel hebben veranderd. Dat toont aan dat zij zelf ook erkennen dat ze het beter horen te doen (bron https://searchunifiedcomm...A-after-82-million-payout)

[Risce]

Het is niet mijn ervaring met het platform, maar ik geloof je direct als mensen zeggen dat Slack in 2020 ook problemen heeft gehad.

[geeMc]

Vlekkeloos? Zo ver zou ik echt niet gaan. Slack is een erg mooi platform met superveel mogelijkheden, maar ligt er om de haverklap uit. In het afgelopen jaar hebben wij als Enterprise Grid klant ongelooflijk veel storingen gezien, meer dan acceptabel.

[jarco5000]

Dit is begrijpelijk maar natuurlijk wel onhandig met het thuiswerken. Nu loop ik constant collega's te bellen waar dit eigenlijk niet nodig is.

[1nsane]

Slack is niet het enige platform wat problemen lijkt te hebben..

Lokale sites lijken hier 9 van de 10 gevallen wel te werken maar alles wat ik “overzees” ophaal lijkt traag of niet goed te werken.

[johanneslol]

Ah cut them some Slack ?

Ik vermoed dat het komt doordat iedereen weer aan het werk is in het nieuwe jaar = extra load

[bedanktjoh]

Super vervelend. We zijn net vandaag 100% remote gegaan en dan gebeurt ons dit.

We zijn (tijdelijk) overgestapt op discord. Werkt voor chat en voice calls prima.

[Ventieldopje]

Nee, je betalingen gaan niet via Slack Wellicht dat er een verband is (ergens een grote verbinding er uit) maar geen direct verband met Slack.