Så kör du bakgrundsjobb i en webbapp: köer, schemaläggare och cron

För att köra bakgrundsjobb i en webbapp delar du först upp arbetet i två typer. Utlösta jobb (skicka ett välkomstmejl, bearbeta en uppladdning) kan sparas i en jobbkö, ofta en tabell i din databas, och hanteras av en worker med omförsök. Schemalagda jobb (en nattlig rapport, påminnelser var 15:e minut) behöver något som utlöses enligt en tidtabell: en cron-funktion hos värden, eller en extern schemaläggare som anropar en skyddad endpoint i din app. Gör alltid jobben säkra att köra två gånger, logga fel och lita aldrig på en timer i en server som kan vila eller starta om.

Den här guiden förklarar alternativen, när varje passar och hur du sätter upp dem med en AI-appbyggare, även på värdar som skalar ner till noll.

Vad som räknas som bakgrundsjobb

Allt som är långsamt, opålitligt eller inte behövs för användarens omedelbara svar:

• Att skicka mejl, aviseringar och kvitton
• Ändra storlek på bilder, koda om video, generera PDF:er
• Anropa långsamma tredjepartstjänster, inklusive AI-modeller för långa uppgifter
• Importera eller synka data från ett annat system
• Nattlig städning, rapporter och påminnelser

Gör du detta inne i förfrågan blir sidorna långsamma och bräckliga: om mejlleverantören är nere misslyckas användarens registrering. Att flytta det till bakgrunden ger användaren ett omedelbart svar och jobbet kan göras om.

Alternativen

Det finns inget enda rätt svar. En liten app behöver ofta bara en databaskö och en extern schemaläggare.

Varför värdar som skalar ner till noll förändrar bilden

Många moderna värdar lägger din app i vila när ingen använder den och väcker den vid nästa förfrågan. Det sparar pengar, men en vilande server kör ingen kod: timers avfyras inte och workers pollar inte. På dessa värdar måste schemalagt arbete starta med en inkommande förfrågan, och den enklaste källan till den förfrågan är en extern schemaläggare. Varje anrop väcker appen (och ofta databasen), så ett anrop varje minut kostar mer än var 15:e minut. Välj det längsta intervall som uppfyller behovet.

Mönster 1: en databaskö för jobb

För utlösta jobb:

1. Skapa en tabell jobs: typ, payload (JSON), status (pending, running, done, failed), attempts, run_after, last_error, tidsstämplar.
2. När något händer infogar du en jobbrad i samma transaktion som ändringen som orsakade det, så att de lyckas eller misslyckas tillsammans.
3. En worker plockar upp jobb som är redo, markerar dem som running, gör arbetet och markerar dem som done.
4. Vid fel ökar du attempts, sätter run_after senare (till exempel 1, 5 och sedan 30 minuter) och sparar felet. Efter ett maxantal markerar du det som failed och larmar någon.

Om fler än en worker kan köra samtidigt måste jobb tas på ett säkert sätt. I Postgres låter SELECT ... FOR UPDATE SKIP LOCKED varje worker ta olika rader utan att krocka.

Vad kör workern? På en alltid igång-server en loop i en separat process. På en värd som skalar ner till noll kan endpointen för schemaläggning i mönster 2 bearbeta en batch förfallna jobb vid varje anrop.

Mönster 2: en extern schemaläggare som anropar din app

För schemalagda jobb:

1. Lägg till en endpoint, till exempel POST /api/cron/send-reminders.
2. Skydda den: kräv en hemlig token i en header, lagrad som hemlighet på båda sidor, och avvisa allt annat.
3. Gör den idempotent: att köra den två gånger samma minut får inte skicka två påminnelser. Registrera vad som skickats.
4. Håll varje anrop kort: bearbeta en batch (säg 100 objekt) och låt nästa anrop ta resten.
5. Peka en schemaläggare mot den.

Val av schemaläggare:

• GitHub Actions schemalagda workflows. Gratis inom GitHubs användningsgränser. Enligt GitHubs dokumentation från september 2026 är kortaste intervallet en gång var 5:e minut, körningar kan fördröjas vid hög belastning (särskilt i början av varje timme), scheman använder UTC som standard, och schemalagda workflows i ett publikt repository inaktiveras efter 60 dagar utan aktivitet i repot.
• Värdbaserade cron-tjänster. Det finns många tjänster vars enda uppgift är att anropa en URL enligt schema. Kontrollera tillförlitlighet, minsta intervall och larm innan du litar på en.
• Din molnleverantörs schemaläggare. Om du redan använder en stor molnleverantör har den en hanterad schemaläggare som kan anropa en HTTPS-endpoint.
• En värdbaserad jobb- eller workflowtjänst. Dessa kombinerar schemaläggning, köer och omförsök och anropar dina endpoints för varje steg. Jämför priser och gränser på varje leverantörs webbplats.

Mönster 3: låt leverantören göra det

Ibland är det bästa bakgrundsjobbet inget alls:

• Betalningar. Stripe gör nya försök för misslyckade prenumerationsbetalningar och skickar webhooks; du reagerar i stället för att polla. Se vad en webhook är.
• E-post. Leverantörer köar och gör nya försök med leveransen när du har lämnat över meddelandet.
• Bulk-AI-arbete. OpenAI och Anthropic erbjuder batch-API:er för icke-brådskande förfrågningar som du skickar in och hämtar senare.

Prompter till din AI-byggare

För en kö:

Lägg till en bakgrundsjobbkö med en tabell jobs i vår databas (typ, payload JSON, status, attempts, run_after, last_error). När en användare registrerar sig, infoga ett send_welcome_email-jobb i samma transaktion i stället för att skicka direkt. Lägg till en funktion processJobs(limit) som tar förfallna jobb med SELECT ... FOR UPDATE SKIP LOCKED, kör dem och gör nya försök efter 1, 5 och 30 minuter, och markerar dem som failed efter 4 försök.

För en schemalagd utlösare:

Lägg till POST /api/cron/tick skyddad av en bearer-token från hemligheten CRON_SECRET; avvisa alla förfrågningar utan den. Varje anrop kör processJobs(100) och skickar bokningspåminnelser som ska skickas inom de närmaste 24 timmarna och som inte redan skickats, och registrerar skickade påminnelser så att inget skickas två gånger. Returnera en JSON-sammanfattning av vad som kördes. Skriv sedan ett GitHub Actions-workflow som anropar endpointen var 15:e minut och läser URL och token från repository-hemligheter.

Vanliga misstag

• Att lita på setInterval. Den stannar tyst när servern vilar eller startar om, och dubblas när två kopior körs.
• En oskyddad cron-endpoint. Vem som helst som hittar den kan utlösa dina jobb, eller din mejlräkning.
• Jobb som inte är idempotenta. Omförsök och dubbla anrop från schemaläggaren kommer att ske. Designa för det.
• Ingen synlighet vid fel. Ett jobb som misslyckas tyst i en vecka är värre än ett som larmar högt. Logga fel och larma vid upprepade misslyckanden.
• Långa körningar i en enda förfrågan. Förfrågningar tar timeout. Bearbeta i batchar.
• För täta scheman. Varje anrop på en värd som skalar ner till noll väcker och debiterar appen. Matcha intervallet med det verkliga behovet.
• Tidszoner. ”Kl. 9” betyder olika saker för din schemaläggare (ofta UTC) och för dina användare. Lagra tider i UTC och omvandla per användare.
• Hemligheter i workflow-filen. Förvara tokens i schemaläggarens hemlighetshantering. Se så håller du API-nycklar säkra.

Checklista

• Långsamt arbete har flyttats ut ur användarens förfrågningar
• Jobb lagras hållbart, inte bara i minnet
• Omförsök med ökande fördröjning och ett maxantal
• Varje jobb är säkert att köra två gånger
• Den schemalagda endpointen är skyddad av en hemlig token
• Varje körning bearbetar en avgränsad batch
• Misslyckade jobb syns, med larm
• Schemats intervall är valt med hostingkostnaden i åtanke
• Tider lagras i UTC

Bakgrundsjobb i Mythex

Mythex dokumentation beskriver inte schemalagda eller cron-jobb, och publicerade appar och deras databaser vilar när de är inaktiva och vaknar vid nästa förfrågan (se Gränser för hosting). Lita därför inte på timers i din app. Det som fungerar är det ovan: be agenten om en jobbtabell och en token-skyddad endpoint, och peka sedan en extern schemaläggare mot din publicerade URL. Lagra token som en projekthemlighet, och kom ihåg att varje uppvakning förbrukar krediter för den tid appen och databasen är vakna, så välj ett rimligt intervall. Behöver din app ett API-backend för detta är REST API-backend-receptet en utgångspunkt, och så bygger du ett REST API beskriver hur du utformar endpointerna. Om alltid igång-workers eller bottar är kärnan i din produkt kan en värd som är byggd för långlivade processer passa dig bättre.

Frågor