Är Grok Bot nere? Fyra fel som liknar ett avbrott – och vad du ska kontrollera först

Om din Grok Bot slutade svara i morse talar oddsen emot att det är ett avbrott hos plattformen, och orsaken är strukturell. Grok Bot är SpaceXAI:s alltid på-kopplade agent, lanserad den 11 augusti 2026, och den körs som en liten flotta av namngivna botar på en molndator som är tilldelad ditt konto. Nästan varje sätt den kan gå sönder på är ett sätt som ger samma symptom – tystnad – medan plattformen i sig är helt frisk. Så det ärliga första svaret på "är den nere?" är att du inte kan avgöra det utifrån symptomet ensamt, och det finns en ordning att kontrollera i som ger dig svaret på ungefär tre minuter.

Ett förbehåll innan checklistan: SpaceXAI:s Bot-dokumentation, så som vi läser den, ger dig en användningsöversikt på kontonivå och körningsposter per rutin, men inget offentligt flöde för drifttid eller incidenter. Det finns ingen sida du kan uppdatera för att få veta om tjänsten är försämrad. Den frånvaron är orsaken till att den här artikeln finns i stället för en länk till en statussida.

De fyra misslyckandena, i den ordning de faktiskt inträffar

Ett: kontot har förbrukat den inkluderade användningen. Det vanligaste – och det som på mest övertygande sätt liknar ett avbrott – eftersom en bot som har nått sitt tak helt enkelt stoppar. Åtkomsten för Grok Bot ingår i betalda Cursor-planer och SuperGrok-nivåer, och mätaren som dokumentationen beskriver är veckovis inkluderad användning på kontot – inte per bot. Den distinktionen är hela fällan: en enda pratglad bot kan förbruka den kvot som fem bottar delar, och utifrån ser det ut som att hela flottan dog på en gång. Usage & Billing visar veckovis inkluderad användning och on-demand-användning för behöriga konton, med en veckovis avläsning i kontomenyn, och en plan som förbrukar sin inkluderade användning kan lägga till on-demand-utgifter som faktureras utifrån modell- och tokenkostnad. En rad i samma FAQ är värd att känna till om du betalar för båda: om du har en Cursor-prenumeration och en SuperGrok-prenumeration använder Boten den som har mer användning.

Två: rutinen är pausad, inte trasig. Rutiner är hur en bot körs enligt ett schema eller efter en händelse, och de är inte garanterade att fortsätta köra under din frånvaro. Dokumentationen noterar att Grok Bot kan fråga om rutinerna ska fortsätta köras efter en lång frånvaro och pausa dem om du inte svarar. En bot som tystnade efter en helgdag, en långhelg eller en oläst prompt befinner sig troligen i exakt det tillståndet.

Tre: datorn återställdes och tog med sig dina installationer. Varje bot på ditt konto delar en dator, med en beständig Linux-yta, en webbläsare, en kommandorad och en delad arbetsyta på code>/workspace/code>. Dokumentationen säger uttryckligen att tillfälliga kataloger, manuellt installerade paket och inte incheckat programtillstånd ska betraktas som utbytbara — och att de två återställningsvägarna skiljer sig: Reset återställer den senast sparade ögonblicksbilden, medan Recreate "tar bort appar och paket som medlemmarna själva har installerat." Om din bot är beroende av något som du installerade manuellt — en kodagent från tredje part, ett CLI, ett bibliotek — kan en återställning ta bort det och lämna en bot som svarar men inte kan utföra sitt jobb. Det uppfattas som ett delavbrott och är egentligen en binärfil som saknas.

Fyra: modellen bakom boten har ändrats, eller försämrats. Cursor hanterar modellvalet. Dokumentationens svar på ”var väljer jag mellan Grok 4.7 och en annan modell” är rakt på sak: det finns ingen modellväljare, ingen inställning per bot, ingen per rutin och ingen per färdighet. Den 7 oktober sa Elon Musk offentligt att Grok Bot inte längre skulle begränsas till SpaceXAI:s egna modeller och i stället skulle sträva efter ”den bästa backend-modellen för varje given uppgift” – ett uttalande utan prislista, utan ändringsloggspost och utan någon extern mätning knuten till sig. Så motorn är ett beslut på plattformssidan som du inte kan se. När den ändras är det du observerar inte ett felmeddelande; det är utdatakvalitet, latens och kostnad som gradvis förändras för samma uppgifter. En bot som plötsligt skriver sämre eller tar längre tid har inte nödvändigtvis legat nere.

Treminuterskontrollen

Kör dessa i ordning och stoppa vid den första som förklarar det du ser:

• Kontots användning först. Öppna kontomenyn och läs den veckovisa inkluderade användningssiffran innan du rör något annat. Om den är uttömd eller nära uttömning misslyckas allt nedströms – varje bot, varje rutin – av en enda orsak, och ingen mängd felsökning av boten hjälper. On-demand-spenderande är spaken, och det är ett faktureringsbeslut, inte ett tekniskt sådant.

• Körningsposter kommer på andra plats.Varje rutin behåller de 20 senaste körningsposterna. Det är en avsiktligt grund revisionslogg, och den räcker fortfarande för att besvara den viktiga frågan: kördes rutinen och misslyckades, eller startade den aldrig? En rutin utan färska poster är pausad eller aldrig utlöst; en rutin med poster som slutar i misslyckande är ett botproblem; en rutin med lyckade poster och ingen synlig utdata är ett problem med utdataleverans.

• Datorn tredje.Fråga boten direkt vad den kan se — code>/workspace/code> innehållet, om ett installerat verktyg fortfarande finns, om en inloggning har överlevt. Eftersom datorn är en maskin för hela kontot och filerna är synliga för varje bot, säger detta dig också om något som en annan bot gjorde har påverkat den här boten.

• Den fjärde triggern. Om boten körs på händelser i stället för enligt ett schema bör du kontrollera triggerns omfattning. Dokumentationen varnar för breda lyssnare som "varje nytt meddelande", vilka skapar brus, förbrukar användningskvot och reagerar på irrelevant indata. En bot som utlöses ständigt men aldrig på ett användbart sätt, eller omvänt, har vanligtvis ett problem med triggerns avgränsning snarare än ett tjänsteproblem.

Först när alla fyra är rena är "plattformen" en rimlig hypotes – och även då är bevisen du har indirekta, eftersom det inte finns något statusflöde att bekräfta den mot.

Varför den delade datorn gör detta svårare än det borde vara

Designen med en enda dator är det mest betydelsefulla med Grok Bot och det minst uppenbara tills något går fel. En dator tilldelas ditt konto i stället för någon enskild bot; skärmarna som varje bot ser beskrivs som "separata arbetsytor, inte separata säkerhetsgränser"; vilken hemlighet som helst kan användas i vilken teammedlems konversation som helst på en Team Bot. Det får två konsekvenser för diagnostiken.

Ett fel är sällan lokalt. En fil som skrivs av din forskningsbot kan läsas av din uppsökande bot, och ett paket som tas bort vid en återställning påverkar varje bot som använde det. För det andra är återställning kontobunden. Att radera en bot tar bort den aktiva profilen, konversationen och rutinerna, medan datorfiler och inloggningar inte är isolerade per bot och kan bestå. Att dölja en bot är det reversibla alternativet; att radera en rutin sker omedelbart och går inte att ångra.

Om du felsöker klockan 2 på natten är den asymmetrin viktigare än någon logg: de operationer som ser ut som städning är de som inte går att ångra.

Vad "status" egentligen skulle kräva

Ett riktigt statusbesked kräver tre saker som Grok Bot inte ger dig i nuläget, och det är värt att nämna dem eftersom de utgör skillnaden mellan en produkt du kan driva och en som du bara kan betrakta:

• En mätare per bot. Användningen mäts på kontonivå, så en flotta som felar tillsammans kan inte delas upp efter vilken bot som orsakade det.

• En djupare körningshistorik. Tjugo poster per rutin räcker för att fånga ett fel den här veckan, men inte för att fånga glidning över en månad — det felmönster som kostar pengar tystlåtet snarare än högljutt.

• Ett incidentflöde. Utan ett sådant är "tjänsten är degraderad" en slutledning utifrån fyra frånvaron snarare än en observation.

Inget av detta är en kritik av produktens design, som är sammanhängande utifrån vad den är: en prenumerationsagent som du konfigurerar genom att prata med den. Det innebär att bevisbördan ligger hos dig varje gång boten tystnar, och kontrollordningen ovan är det billigaste sättet att bära den.

Var en router passar in, och var den inte gör det

Grok Bot är en prenumerationsprodukt, inte något man kan dirigera via en tredjepartsslutpunkt, och ingen ärlig guide borde antyda något annat. Frågan som problemet med modellval väcker är en annan: om du medvetet behöver välja motorn – av kostnadsskäl, av licensskäl, för reproducerbarhet av ett resultat – kan det kravet inte uttryckas inuti boten alls. Det måste ligga i lagret under.

Det lagret är det vi säljer. OrcaRouter är en OpenAI-kompatibel slutpunkt över 200 modeller utan påslag på leverantörens listpris, så en leverantörs prissänkning slår igenom samma dag. Grok 4.6 finns på den till SpaceXAI:s eget publicerade pris på 2,00 USD per miljon inputtokens och 6,00 USD per miljon outputtokens, med ett kontextfönster på 500 000 token och en uppmätt p50-tid till första token på 1,65 sekunder. De delar som spelar roll när ett obeprövat steg misslyckas är de som hindrar ett fel från att bli en incident: automatisk failover mellan leverantörer när en leverantör försämras, ett routing-DSL som kombinerar flera modeller till ett anrop och modellfusion för paneler som svarar tillsammans.

Den praktiska åtgärden för alla som läser det här därför att deras bot har tystnat är den tråkiga. Skriv färdigheten, kör den en gång för hand mot modellen som du hade tänkt lita på, och automatisera den först därefter. En bot som har validerats mot en modell som du kan anropa direkt är en bot vars fel du kan attribuera – och attribuering, inte drifttid, är vad ”är den nere?” egentligen frågar efter.