Google Agenda is voor veel gebruikers onbereikbaar door storing - update 2

Google Agenda is voor veel gebruikers niet bereikbaar door een storing. Het bezoeken van de website levert een 404-foutmelding op. Google zegt het probleem te onderzoeken. Het is nog niet duidelijk wanneer de agenda weer bereikbaar is.

De webversie van Google Agenda levert een 404-pagina op als gebruikers die proberen te benaderen. Via de apps voor Android en iOS lijkt de agenda zonder problemen te functioneren. Andere Google-diensten zijn voor zover bekend niet getroffen.

Google bevestigt dinsdagmiddag op het G Suite Status Dashboard dat er een probleem is met Google Agenda. Het is niet bekend wat het probleem precies is en hoeveel gebruikers er getroffen zijn. Google zegt te werken aan een oplossing.

Update 19:07: Google meldt op de statuspagina dat het nog bezig is met het oplossen van het probleem en dat het naar verwachting om 19:40 uur is opgelost.

Update 19:25: Google zegt het probleem om 19:13 uur verholpen te hebben. Meer details over de problemen zijn niet bekendgemaakt.

Reacties (60)

[Randfiguur]

Toevallig(?) is ook de webversie van Instagram sinds in ieder geval 17u voor mij onbereikbaar. Ook hier doet de app het wel gewoon.

[Sharkoon]

gmail had ook even problemen, kon geen mail schrijven

[dakathefox]

Inderdaad. Viel mij ook al op.

[Plompie]

Begin van de maand hadden ze ook al een flinke storing op het cloud platform. Zou er iets aan zitten te komen bij Google?

https://www.google.com/ap...v=status&ts=1559685599000

[CH4OS]

Ik begrijp even niet waarom een storing zou impliceren dat er iets aan zit te komen bij Google? Voor hetzelfde geldt is het gewoon een DDoS aanval oid en is daarom het entrypoint afgesloten, waardoor het nu een HTTP 404 status teruggeeft en geen HTTP 503, wat het eerder deed.

[AW_Bos]

Een DDoS houd je niet tegen door je entrypoint om te sluizen naar een 404 of 503. De pijp naar de server blijft in zo een geval een hoop requests krijgen dat deze vol komt te zitten.

[YouryDW]

Als het een DDoS zou zijn dan is het tactisch beter om een omleiding te zetten naar een static 404 pagina die slecths 535 Bytes groot is (zoals de huidige) in plaats van whatever andere pagina die veel groter zou zijn, verder zal een 404 in andere implentaties vaak ook in een totaal andere (vaak niet voorziene) flow terecht komen en dus meer kans hebben op het ontbreken van retry mechanismes voor eventuele requesten van de miljoenen gebruikers...

[djwice]

Of gewoon een 201 (no content : you already have it), 429 (to many requests : you ddos) of 451 (unavailable for legal reasons : jij hacker = stout) ;-)

[CH4OS]

Bij een DDoS wil je requests zsm afgehandeld hebben, dat is het snelst door gewoon een HTTP 404 terug te geven, zo voorkom je overbodige load op je serverpark.

[djwice]

Waarom een 404 en niet een 201?

[CH4OS]

De HTTP 200 statussen zijn 'succes' statussen. Je wilt een aanvaller niet wijzer maken dan dat 'ie is. Met HTTP 400 (fout)meldingen worden geen verdere acties gedaan en houdt het gewoon op; het verzoek wordt dan immers afgekapt.

[djwice]

Met een 400-melding geef je toch just informatie dat zijn request is geanalyseerd en door de server op een bepaalde manier is gerelateerd aan de content? Met een 201 (no content) geef je een minimale response waar hij niets mee kan (geen body).

[CH4OS]

Dan weet de aanvaller dat de URL correct is en dus die URL kan hammeren, totdat de DDoS succesvol afgeslagen wordt. Nogmaals, HTTP 200 statussen zijn succes statussen, die wil je niet aan een aanvaller afgeven tijdens een DDoS... Je wil de requests zsm terminaten en hem zo min mogelijk wijzer maken. Met HTTP 200 statussen geef je dus aan dat de aanvaller goed zit.

[Reactie gewijzigd door CH4OS op 23 juli 2024 07:58]

[djwice]

Waarom niet gewoon als het 400-range is een 201 sturen, dan denkt de aanvaller dat ie goed zit, maar schiet mis.

[CH4OS]

Ik ga mijzelf niet blijven herhalen, lees de bovenstaande reacties even nogmaals door.

[Nathan13877]

404 is een erg rare statuscode om terug te sturen in geval van een DDOS. 404 zou moeten betekenen dat de server geprobeerd heeft om je request path te vinden, maar niets heeft gevonden. 429 of 503 is veel logischer.

Verder is je redenering dat een 404 het snelste is volledig fout.

Bij een DDoS wil je requests zsm afgehandeld hebben, dat is het snelst door gewoon een HTTP 404 terug te geven, zo voorkom je overbodige load op je serverpark.

Een status code heeft helemaal niks te maken met de snelheid, het maakt precies niks uit of je als server een 200 of een 400 terugstuurt. De statuscode is bedoelt om clients te informeren, maar het doet uit zich zelf precies niks.

[Verwijderd]

Valt wel mee uiteindelijk hoor want niet iedereen heeft er last van. Microsoft cloud heeft ook regelmatig storingen en daar merk je vaak niets van. Deze en de vorige heb ik ook niets van gemerkt of gehoord bij klanten.

[dutchlion123]

Bij mij werkt het sinds twee minuten weer, maar ik krijg wel een popup met de vraag "links voor online agenda openen" Toestaan of Blokkeren? Weet iemand wat de consequenties van deze keuzes?

[Verwijderd]

Doe eens 'toestaan' en laat ons weten wat er gebeurd. Daarna test ik wel even 'blokkeren'....

[dutchlion123]

Ik had de melding al weggeklikt. Als hij weer verschijnt, zal ik eens verder uitzoeken wat er gebeurt.

[AW_Bos]

En toen deed hij het weer, maar een deel dan. Echter kon hij mijn agenda items nog niet laden. Niet zo een groot probleem omdat die toch in mijn telefoon staan.

[Reactie gewijzigd door AW_Bos op 23 juli 2024 07:58]

[The Ghost]

Hier werkt alles als normaal, zowel de webversie als op mijn telefoon.

[theorganiser]

Hmm, we gebruiken zakelijk al een jaar of 7 al Google agenda.

Echter het laatste half jaar komen er steeds meer kuren in.
Begon dat als je op vandaag klikte een random datum kreeg (3/4 weken verschil.)
Ook is het aanpassen van tijdsblokken een stuk lastiger geworden.

[beerse]

Heeft het iets te maken met de grote hoeveelheid agenda afspraken die ik de laatste weken krijg? Vooral de spam folders lopen over.

Er schijnt iets te zijn met een hack via een afspraak in Gmail, vooral als je die afspraak automatisch laat verwerken.

[Zidane007nl]

Ik kreeg eerst een captcha die ik moest invullen vanwege dat er ongebruikelijk verkeer vanaf het IP adres kwam. Na het invullen kreeg ik een HTTP 404 pagina te zien.
Naast deze storing tevreden over Google Calendar.

[faim]

Via de apps voor Android en iOS lijkt de agenda zonder problemen te functioneren.

De API is inderdaad gewoon bereikbaar.

Waarschijnlijk heeft de front-end stagiaire een en ander per ongeluk verwijderd

[Sharkoon]

De API is ook niet beschikbaar, hier heb ik juist problemen mee!

Waarschijnlijk wordt er iets anders voor Android of iOS gebruikt

[Turbo-Puppy]

Zou toch wel fijn zijn als er een soort cache functie kwam waar je naar kunt schrijven. Dit is best irritant... het ligt er uit, en je kunt ook niets. De afspraken en data zijn niet eens nu nodig, en als die er vannacht in zouden staan door een sync met een cache oplossing dan was dat prima.

Nu kan ik dus heel de avond controleren of het werkt, en daarna nog alles er in.
Volgens mij moet daar wel een tussenoplossing voor te bedenken zijn. (Alhoewel dit misschien ook wel meer aan het ERP pakket dan aan Google ligt)

Anyway... het was voor nu een wenselijke oplossing geweest.

[djwice]

Zo maak je je agenda offline beschikbaar:
https://sites.google.com/...y-google-calendar-offline

En dan kun je ook nieuwe afspraken aanmaken:
https://support.google.com/calendar/answer/1340696?hl=nl

[Reactie gewijzigd door djwice op 23 juli 2024 07:58]

[Verwijderd]

https://support.google.com/calendar/answer/1340696?hl=nl

[djwice]

Zolang je device maar https://chrome.google.com/webstore/ ondersteunt :-)

[Tokkes]

Klopt - Slackbots hier liggen eruit.

[Bosmonster]

Kreeg eerst een melding over overbelasting, daarna een 503 en toen hebben ze het veranderd in een 404. Dus denk dat ze voor het gemak tijdens het onderzoeken/oplossen de entry point maar even disabled hebben.

[Reactie gewijzigd door Bosmonster op 23 juli 2024 07:58]

[AW_Bos]

In een complexe infrastructuur kan het ook wel spontaan wisselen. Overbelasting, foute loadbalancer etc.....

[DigitalExorcist]

Index.htm ? 😜

[Blizz]

https://gsuite.google.com/intl/en/terms/sla.html

Uptime dipt nu wel onder het SLA-minimum, vraag je geld terug.

[Zen1581]

does not apply to any performance issues caused by factors described in the "Force Majeure" section of the Agreement

Als er sprake is van een Ddos aanval of iets dergelijks, waarbij derden het gemunt hebben op Google, is de kans vrij klein dat je hier aanspraak op kan maken. Ook door bijvoorbeeld een elektriciteitsstroring bij hun datacenters is er geen recht op vergoeding. Meestal hebben grote bedrijven dit zeer goed afgedekt. Zolang de fout dus niet bij Google ligt, is de kans klein dat ze hierheen mee willen gaan

[Soldaatje]

Het is hoe dan ook geen goede reclame voor een bedrijf. De storing is al vervelend maar daarna de klanten ook niet tegemoet komen, dat kan ze (toekomstige) klanten kosten.

[dakathefox]

Google heeft gewoon een prima regeling waarin het klanten tegemoet komt in het geval van storingen. Je stelling slaat als een tang op een varken.

[Soldaatje]

Mijn punt is dat een storing ongeacht de oorzaak nooit goede reclame is voor een bedrijf. Nou kan dat natuurlijk buiten de schuld van het bedrijf liggen maar daar heeft de klant natuurlijk niks aan. Uiteindelijk is het gevaarlijk voor het voortbestaan van het bedrijf.

[b12e]

Hoe en waar dien je zo’n claim in?

Ik was niet eens op de hoogte hiervan, betaal al sinds enkele jaren voor mijn Gsuite/Gapps omgeving....