Ligt Grok Bot eruit? Vier storingen die op een uitval lijken, en wat je eerst moet controleren

Als je Grok Bot vanochtend niet meer antwoordde, is de kans klein dat dit een platformstoring is, en de oorzaak is structureel. Grok Bot is de altijd actieve agent van SpaceXAI, gelanceerd op 11 augustus 2026, en draait als een kleine vloot bots met eigen namen op een cloudcomputer die aan jouw account is toegewezen. Vrijwel elke manier waarop hij uitvalt, veroorzaakt hetzelfde symptoom — stilte — terwijl het platform zelf volledig gezond is. Het eerlijke eerste antwoord op de vraag „Is het down?” is dus dat je dat niet alleen aan het symptoom kunt zien, en er is een volgorde om te controleren die je in ongeveer drie minuten tot het antwoord leidt.

Eén voorbehoud vóór de checklist: de Bot-documentatie van SpaceXAI biedt, zoals wij die lezen, een gebruiksoverzicht op accountniveau en uitvoeringsverslagen per routine, maar geen openbare uptime- of incidentfeed. Er is geen pagina die je kunt verversen om te weten of de dienst verslechterd is. Dat dit ontbreekt, is de reden dat dit artikel bestaat en niet gewoon een link naar een statuspagina.

De vier fouten, in de volgorde waarin ze daadwerkelijk optreden

Eén: het account heeft zijn inbegrepen gebruik uitgeput. Het meest voorkomende geval, en het geval dat een storing het overtuigendst nabootst, omdat een bot die zijn plafond heeft bereikt gewoon stopt. De toegang van Grok Bot is gebundeld in betaalde Cursor-abonnementen en SuperGrok-tiers, en de meter die de documentatie beschrijft is wekelijks inbegrepen gebruik op het account — niet per bot. Die distinctie is de hele val: een enkele kletsgrage bot kan de toelage uitputten die vijf bots delen, en van buitenaf ziet het eruit alsof de vloot ineens is gestorven. Gebruik & Facturering toont wekelijks inbegrepen gebruik en gebruik op aanvraag voor in aanmerking komende accounts, met een wekelijkse uitlezing in het accountmenu, en een abonnement dat zijn inbegrepen gebruik uitgeput heeft, kan uitgaven op aanvraag toevoegen die worden gefactureerd op basis van model- en tokencost. Eén regel in dezelfde FAQ is het weten waard als je voor beide betaalt: als je een Cursor-abonnement en een SuperGrok-abonnement hebt, put de Bot degene met meer gebruik.

Twee: de routine is gepauzeerd, niet kapot. Routines zijn hoe een bot volgens een schema of na een gebeurtenis draait, en ze lopen niet gegarandeerd door tijdens je afwezigheid. De documentatie vermeldt dat Grok Bot kan vragen of routines na een lange afwezigheid moeten doorlopen, en ze kan pauzeren als je niet antwoordt. Een bot die stilviel na een vakantie, een lang weekend of een ongelezen prompt, zit hoogstwaarschijnlijk precies in die staat.

Drie: de computer werd gereset en nam je installaties mee. Elke bot op je account deelt één computer, met een persistente Linux-omgeving, een browser, een opdrachtregel en een gedeelde werkruimte op code>/workspace/code>. De documentatie stelt expliciet dat tijdelijke mappen, handmatig geïnstalleerde pakketten en niet-gecommitte applicatiestatus als vervangbaar moeten worden behandeld — en dat de twee herstelpaden verschillen: Reset herstelt de laatst opgeslagen snapshot, terwijl Recreate "apps en pakketten verwijdert die leden zelf hebben geïnstalleerd." Als je bot afhankelijk is van iets dat je handmatig hebt geïnstalleerd — een codingagent van een derde partij, een CLI, een bibliotheek — kan een herstel dat verwijderen en een bot achterlaten die antwoordt maar zijn werk niet kan doen. Dat ziet eruit als een gedeeltelijke storing en is eigenlijk een ontbrekende binary.

Vier: het model achter de bot is veranderd of verslechterd. Cursor beheert de modelselectie. Het antwoord in de documentatie op "waar kies ik tussen Grok 4.7 en een ander model" is onomwonden: er is geen modelkiezer, geen instelling per bot, geen per routine en geen per skill. Op 7 oktober zei Elon Musk publiekelijk dat Grok Bot niet langer beperkt zou blijven tot de eigen modellen van SpaceXAI en "het beste back-endmodel voor elke gegeven taak" zou kiezen — een uitspraak waaraan geen tariefkaart, geen changelog-vermelding en geen externe meting is gekoppeld. Dus de engine is een beslissing aan de platformzijde die je niet kunt zien. Wanneer die verandert, is wat je waarneemt geen foutmelding; het is outputkwaliteit, latency en kosten die bij dezelfde taken verschuiven. Een bot die plotseling slechter schrijft of er langer over doet, is niet noodzakelijkerwijs uitgevallen.

De drieminutencheck

Voer deze in volgorde uit en stop bij de eerste die uitlegt wat je ziet:

• Accountgebruik eerst. Open het accountmenu en lees het wekelijks inbegrepen gebruikscijfer voordat je iets anders aanraakt. Als het uitgeput of bijna uitgeput is, mislukt alles daarna — elke bot, elke routine — om één reden en geen enkele hoeveelheid debuggen van de bot zal helpen. On-demand uitgaven zijn de hefboom, en dat is een factureringsbeslissing, geen technische.

• Daarna de uitvoeringsrecords.Elke routine houdt de 20 meest recente uitvoeringsrecords bij. Dat is een bewust beperkt auditspoor, en het is nog steeds genoeg om de vraag te beantwoorden die ertoe doet: is de routine uitgevoerd en mislukt, of is ze nooit gestart? Een routine zonder recente records is gepauzeerd of nooit getriggerd; een routine met records die op een mislukking eindigen is een botprobleem; een routine met geslaagde records en geen zichtbare output is een probleem met de outputlevering.

• Ten derde: de computer.Vraag de bot direct wat hij kan zien — code>/workspace/code>-inhoud, of een geïnstalleerd hulpmiddel nog bestaat, of een aanmelding nog geldig is. Omdat de computer één machine is voor het hele account en bestanden voor elke bot zichtbaar zijn, vertelt dit je ook of iets dat een andere bot heeft gedaan deze bot heeft beïnvloed.

• Ten vierde: de trigger. Als de bot op gebeurtenissen draait in plaats van volgens een schema, controleer dan de reikwijdte van de trigger. De documentatie waarschuwt tegen brede listeners zoals "elk nieuw bericht", die ruis genereren, quota verbruiken en op irrelevante input reageren. Een bot die constant vuurt maar nooit nuttig is, of juist het omgekeerde, wijst meestal op een probleem met de afbakening van de trigger en niet op een probleem met de service.

Pas nadat alle vier schoon zijn, is "het platform" een redelijke hypothese — en zelfs dan is het bewijs dat je hebt indirect, omdat er geen statusfeed is om het tegen te bevestigen.

Waarom de gedeelde computer dit moeilijker maakt dan nodig is

Het single-computerontwerp is het meest ingrijpende aspect van Grok Bot en het minst voor de hand liggende todat er iets misgaat. Eén computer wordt aan je account toegewezen, niet aan een individuele bot; de schermen die elke bot ziet, worden beschreven als "aparte werkoppervlakken, geen aparte veiligheidsgrenzen"; elk geheim kan in elk gesprek van een teamgenoot op een Team Bot worden gebruikt. Dat heeft twee gevolgen voor de diagnose.

Ten eerste is een storing zelden lokaal. Een bestand dat door je onderzoeksbot is geschreven, is leesbaar voor je outreachbot, en een pakket dat tijdens een reset wordt verwijderd, beïnvloedt elke bot die het gebruikte. Ten tweede is herstel accountgebonden. Het verwijderen van een bot verwijdert het actieve profiel, het gesprek en de routines, terwijl computerbestanden en aanmeldingen niet per bot zijn geïsoleerd en kunnen blijven bestaan. Een bot verbergen is het omkeerbare alternatief; het verwijderen van een routine is onmiddellijk en kan niet ongedaan worden gemaakt.

Als je om 2 uur 's nachts aan het debuggen bent, is die asymmetrie belangrijker dan welk log dan ook: de handelingen die op opruimen lijken, zijn juist degenen zonder weg terug.

Wat "status" feitelijk zou vereisen

Een echt statusantwoord vereist drie dingen die Grok Bot je momenteel niet biedt, en het is de moeite waard ze te benoemen, omdat ze het verschil vormen tussen een product dat je kunt bedienen en een dat je alleen kunt bekijken:

• Een meter per bot. Gebruik wordt op accountniveau gemeten, dus een vloot die als geheel faalt, kan niet worden uitgesplitst naar de bot die het veroorzaakte.

• Een diepere uitvoeringsgeschiedenis. Twintig records per routine zijn genoeg om deze week een storing te vangen, maar niet genoeg om drift over een maand te vangen — de faalmodus die geld kost, geruisloos eerder dan luid.

• Een incidentenfeed. Zonder die feed is "de dienst is verslechterd" een gevolgtrekking uit vier afwezigheden, geen waarneming.

Niets daarvan is kritiek op het ontwerp van het product, dat coherent is voor wat het is: een abonnementsagent die je configureert door met hem te praten. Het betekent wel dat de bewijslast elke keer dat de bot zwijgt bij jou ligt, en de controleorde hierboven is de goedkoopste manier om die te dragen.

Waar een router past, en waar niet

Grok Bot is een abonnementsproduct, niet iets dat je via een endpoint van derden kunt routeren, en geen enkele eerlijke gids zou iets anders suggereren. De vraag die het probleem van modelselectie oproept, is anders: als je de engine bewust moet kiezen — voor kosten, voor een licentie, voor reproduceerbaarheid van een resultaat — dan kan die vereiste überhaupt niet binnen de bot worden uitgedrukt. Die moet in de laag daaronder leven.

Die laag is wat we verkopen. OrcaRouter is één OpenAI-compatibel endpoint over meer dan 200 modellen, zonder opslag op de lijstprijs van de provider, zodat een prijsverlaging van een leverancier dezelfde dag live is. Grok 4.6 staat erop tegen SpaceXAI's eigen gepubliceerde tarief van $2,00 per miljoen inputtokens en $6,00 per miljoen outputtokens, met een contextvenster van 500.000 tokens en een gemeten p50 time to first token van 1,65 seconden. De onderdelen die van belang zijn wanneer een onbewezen stap mislukt, zijn de onderdelen die voorkomen dat een fout een incident wordt: automatische failover tussen providers wanneer er één achteruitgaat, een routing-DSL die meerdere modellen samenstelt tot één aanroep, en model fusion voor panels die samen antwoorden.

De praktische stap voor iedereen die dit leest omdat zijn bot is stilgevallen, is de saaie. Schrijf de skill, voer hem één keer handmatig uit tegen het model dat je ging vertrouwen, en automatiseer het pas daarna. Een bot die is gevalideerd tegen een model dat je direct kunt aanroepen, is een bot waarvan je de fouten kunt toeschrijven — en toeschrijving, niet uptime, is wat de vraag "is het down?" eigenlijk vraagt.