Ett schemalagt jobb har ingen användare som klagar när det går fel, så beställningen måste göra felen synliga. Skriv vad jobbet gör, när det körs uttryckt i svensk tid, vem som får resultatet och vem som får besked när det misslyckas. Beställ ett provläge som bara skickar till dig, ett skydd mot dubbla utskick och ett besked när en körning uteblivit. Prova sedan fyra saker med känt facit: kör nu, kör två gånger, fel tidszon och missad körning. Sommartiden slutar söndag 25 oktober 2026, och dagen efter är ett bra tillfälle att läsa körhistoriken.
Tre sorters jobb som körs utan att någon klickar
Det mesta i en app händer för att någon trycker på en knapp. Då finns det också någon som ser om det gick fel. Schemalagda jobb är undantaget: de startar av sig själva vid en viss tid och gör sitt arbete utan publik. Tre sorter är vanliga i de appar den här sajten skriver om.
Påminnelsen skickar något till en användare vid en viss tidpunkt – ett mejl dagen före en bokning, ett meddelande när en faktura förfaller. Felet syns hos mottagaren, om det alls syns. Rensningen tar bort eller arkiverar det som blivit gammalt – utgångna inbjudningar, avbrutna utkast, loggrader äldre än en månad. Felet syns först när något saknas eller när databasen vuxit. Sammanställningen samlar dagens eller veckans läge och skickar det till dig – nya anmälningar, obetalda fakturor, dagens bokningar. Felet syns som en tom inkorg en morgon, och tystnad är lätt att tolka som att inget hänt.
Gemensamt för alla tre är att ett fel kan vara helt tyst. Därför handlar resten av den här artikeln om det som gör tystnaden hörbar: ett besked vid fel, en körhistorik du vet var du hittar, och fyra prov du kör innan du litar på jobbet.
Vad verktygen själva visar om sina jobb
Tre verktyg dokumenterar sina schemalagda jobb så att det går att hänvisa till. Uppgifterna nedan är hämtade ur deras dokumentation 25 september 2026. De beskriver var jobben syns och vad som loggas, men ingen av sidorna säger vad som händer vid sommartidsskifte, efter en missad körning eller om samma körning startar två gånger. Därför är det just de sakerna du provar själv.
0 9 * * 1-5 betyder vardagar klockan 9 – och du väljer tidszon. Inställningarna har en tidsgräns för jobbet (job timeout), du betalar för varje körnings längd, och du får ett larm om en körning misslyckas. Var körhistoriken visas står inte på den sidan.cron.job_run_details, och knappen History bredvid jobbets namn visar körningarna. Supabase rekommenderar högst 8 jobb samtidigt och högst 10 minuter per jobb. Två saker är värda att veta: ett nytt jobb med samma namn skriver över det gamla, och körhistoriken rensas inte automatiskt.Lägg märke till vad statusen mäter. Succeeded betyder att körningen gick igenom, inte att brevet kom fram eller att det gick till rätt person. Om leveransen fallerar är det en egen felkälla, och den har en egen artikel: appens mejl kommer aldrig fram. Kontrollera att vanliga utskick landar innan du felsöker jobbet som skickar dem.
Fyra frågor beställningen ska svara på
”Skicka en påminnelse dagen före” är en önskan, inte en beställning. Den svarar inte på fyra frågor, och varje obesvarad fråga blir ett beslut någon annan fattar åt dig.
Vad. Vilka poster jobbet tittar på och vad det gör med dem. ”Bokningar med datum i morgon som inte är avbokade” är en regel som går att räkna efter. ”Kommande bokningar” är det inte. När. Klockslag och tidszon, i samma mening: ”klockan 08:00 svensk tid, Europe/Stockholm”. Ett klockslag utan tidszon tolkas i någon tidszon, och det är inte säkert att det är din. För vem. Vem som får utskicket och från vilken adress, och vem som inte ska få det – avbokade, testkonton, personer som tackat nej till påminnelser. Vid fel. Vem som får besked när en körning misslyckas, vad beskedet ska innehålla och vad som händer med de utskick som inte gick iväg. Beskedet ska kunna läsas av någon som inte byggt appen, på samma sätt som en användbar felrapport.
Till det kommer tre skydd som gör proven möjliga: ett provläge där allt går till dig, en regel som hindrar att samma påminnelse skickas två gånger, och en körlogg i appen som gör att nästa körning märker att den förra uteblev.
Tidszon och sommartid: 25 oktober 2026
Enligt förordningen om sommartid upphör sommartiden klockan 03.00 den sista söndagen i oktober, och tiden anges då som 02.00. I år är det söndag 25 oktober 2026. Den natten inträffar timmen mellan 02 och 03 två gånger. På våren är det tvärtom: sista söndagen i mars – 28 mars 2027 – hoppar klockan från 02.00 till 03.00, och den timmen finns inte alls. Ett jobb som ska köras en gång per natt hör därför inte hemma mellan 02 och 03. Lägg det före eller efter.
Det andra problemet är räkning. Klockan 08:00 svensk tid är 06:00 i UTC (den gemensamma världstiden som servrar ofta räknar i) under sommartid, och 07:00 i UTC efter 25 oktober. Ett jobb som låsts till 06:00 UTC skickar därför påminnelsen klockan åtta hela sommaren och klockan sju hela vintern, utan att något ser fel ut i schemat. Ett jobb som av misstag ställts på 08:00 UTC skickar just nu klockan tio svensk tid. Det är skillnaden på två timmar du letar efter i prov 3.
Vad varje verktyg gör med ett schema när klockan ställs om står inte i dokumentationen ovan, och det ska du inte gissa. Beställ i stället svensk tid uttryckligen, be verktyget skriva ut körningarna 23–27 oktober med datum och klockslag, och läs körhistoriken måndag 26 oktober.
Beställningen: en påminnelse dagen före bokningen
Texten nedan är skriven för en app med bokningar. Byt ut det som står i hakparenteser mot dina egna namn, men behåll de sju delarna i ordning: vad, när, för vem, vid fel, dubbletter, missad körning och provläge. Den sista meningen gör resten kontrollerbart.
Skapa ett schemalagt jobb som heter [bokningspaminnelse]. Vad: Jobbet hittar alla [bokningar] med datum i morgon som inte är avbokade, och skickar ett mejl till bokningens e-postadress med tid och plats. Jobbet ändrar ingenting annat i registret. När: Varje dag klockan 08:00 svensk tid (Europe/Stockholm), både under sommartid och vintertid. Skriv ut körningarna 23–27 oktober 2026 med datum och klockslag i svensk tid och i UTC, så att jag ser att tiden inte flyttar sig när sommartiden slutar 25 oktober. För vem: Bara bokningens egen adress. Ingen påminnelse till avbokade bokningar eller till konton markerade som test. Vid fel: Om jobbet misslyckas, eller om ett enskilt mejl inte kan skickas, ska jag få ett mejl till [min adress] med tid för körningen, vilka bokningar som inte fick sin påminnelse och felet i klartext. Dubbletter: Spara för varje bokning att påminnelsen är skickad och när. Kör jobbet igen samma dag ska samma bokning inte få en påminnelse till. Missad körning: Skriv varje körning i en körlogg i appen med start, slut och antal skickade. Om förra lyckade körningen är äldre än planerat ska nästa körning mejla mig hur många körningar som saknas sedan när, och sedan skicka de påminnelser som fortfarande gäller, en gång var. Påminnelser för bokningar som redan har passerat ska inte skickas i efterhand, utan listas i beskedet. Provläge: Lägg till ett provläge som jag slår på och av. I provläge går varje mejl till [min adress] i stället för till mottagaren, med ämnesraden inledd av [PROV] och den riktiga mottagaren angiven i texten. Lägg till en knapp på adminsidan som kör jobbet en gång nu, bara när provläget är på. Innan du bygger: beskriv i klartext, utan kodord, vad jobbet kommer att göra i vart och ett av de fyra proven nedan.
Två rader kan du vilja ändra. Ska missade påminnelser skickas i efterhand ändå, skriv det och ändra facit för prov 4. Och körloggen i appen ersätter inte verktygets körhistorik: verktygets historik visar att jobbet startade, appens körlogg visar vad det gjorde. Rensningsjobb och sammanställningar beställer du med samma sju delar – byt bara ut ”vad” och ”för vem”.
Fyra prov med facit
Proven körs med provläget påslaget och fyra påhittade bokningar. Skriv facit på ett papper innan du provar, så att du jämför mot det du väntade dig och inte mot det du ser. Alla utskick hamnar hos dig, så inga riktiga användare berörs.
Testbokningar (provläget på, alla med din egen adress): A i morgon kl. 10 ej avbokad B i morgon kl. 14 ej avbokad C i övermorgon ej avbokad D i morgon kl. 16 AVBOKAD Prov 1: Kör nu Gör: tryck på knappen som kör jobbet en gång. Facit: 2 mejl till dig, med [PROV] i ämnet, för A och B. Inget för C (fel dag) och inget för D (avbokad). Körloggen i appen har en ny rad med antal skickade: 2. Prov 2: Kör två gånger Gör: tryck på knappen igen direkt. Facit: 0 nya mejl. Körloggen har en rad till, med antal skickade: 0. Kommer två mejl till fungerar inte dubblettskyddet, oavsett vad statusen säger. Prov 3: Fel tidszon Gör: be om den skrivna listan över körningarna 23–27 oktober. Facit: 08:00 svensk tid på alla fem raderna. I UTC står 06:00 för 23 och 24 oktober och 07:00 för 25, 26 och 27 oktober 2026. Lägg sedan till bokning F i morgon och ställ tillfälligt jobbet på en tid tio minuter fram, i svensk tid. Facit: 1 mejl, för F, vid den tiden med några minuters marginal. Kommer det två timmar senare räknar jobbet i UTC (efter 25 oktober är skillnaden en timme). Prov 4: Missad körning Gör: ställ tillfälligt jobbet på var 15:e minut, stäng av det i 40 minuter och slå sedan på det igen. Facit: vid nästa körning 1 mejl till dig som säger att körningar saknas och sedan när. Inga nya påminnelser för A, B och F, som redan fått sina. Lägg till en bokning E i morgon medan jobbet är avstängt: E ska få 1 påminnelse, inte fler. Efteråt: ställ tillbaka schemat till 08:00 svensk tid och stäng av provläget.
Läs av i ordning och stanna vid första avvikelsen. Ger prov 1 tre mejl, se efter vilken bokning det tredje gäller: D betyder att avbokningen inte kommit med i regeln, C att datumregeln tar med fel dag. Det är den raden du beställer om. Ger prov 2 två nya mejl saknas dubblettskyddet. Det är det fel som kostar mest i verkligheten, eftersom ett jobb kan starta två gånger av skäl som inte syns – en ändring i chatten som skapar ett nytt jobb bredvid det gamla, eller ett omförsök efter ett tillfälligt fel. I Supabase skriver ett nytt jobb med samma namn över det gamla, medan ett nytt namn ger två jobb bredvid varandra. Därför ger beställningen jobbet ett fast namn.
Ett jobb som körs var 15:e minut och skickar skarpt är fyra utskick i timmen till varje riktig mottagare. Prova med provläget påslaget och testbokningarna, ställ tillbaka schemat, och kontrollera i verktygets vy att schemat verkligen står på 08:00 innan provläget stängs av. I Lovable står det i klartext i Jobs-vyn.
Prov 4 bygger på att jobbet går att stänga av en stund. I Lovable gör du det med Disable i Jobs-vyn. I de andra verktygen får du be om det i chatten eller pausa schemat på det sätt verktyget erbjuder. Vad verktyget självt gör med de körningar som skulle ha skett under pausen står inte i dokumentationen, och det är därför beställningen låter appen upptäcka luckan i stället för att lita på verktyget.
Var körhistoriken syns
Skriv ned var du läser historiken innan du behöver den. I Lovable är det More → Cloud → Jobs, där du klickar på jobbet och får tabellen med start, slut och status i din tidszon – tryck Refresh, annars ser du ett gammalt läge. I Supabase är det knappen History bredvid jobbets namn, eller tabellen cron.job_run_details. Eftersom den tabellen inte rensas automatiskt är den själv ett rimligt första rensningsjobb. För Replit anger sidan om schemalagda körningar att du får larm när en körning misslyckas, men inte var historiken visas; leta upp det i publiceringsverktyget och skriv ned var.
Läs sedan två saker samtidigt: verktygets historik och appens körlogg. Står det en körning i den ena men inte i den andra har jobbet startat utan att göra sitt arbete, eller gjort sitt arbete i ett jobb du inte visste fanns. Och lägg in en fast avläsning: måndag 26 oktober 2026, dagen efter att sommartiden slutat, ska påminnelsen ha gått klockan 08:00 och historiken visa en körning, inte noll och inte två.
Tätheten kostar också. Lovable anger att täta eller långa jobb ökar projektets krediter och att schemalagda jobb håller ett projekt aktivt, Replit att du betalar för varje körnings längd, och Supabase rekommenderar högst 10 minuter per jobb. Ett jobb som körs var 15:e minut är 96 körningar per dygn; ett som körs klockan åtta är en. Välj det glesaste schema som gör jobbet.
Var beställningen slutar
Beställningen säger ingenting om hur jobbet byggs, och det är avsiktligt. Föreslår verktyget ett cron-uttryck, en funktion eller en egen tabell behöver du inte bedöma tekniken. Du behöver kontrollera att de fyra proven ger facit. Svarar verktyget med ett schema i UTC, be det räkna om till svensk tid och skriva ut körningarna 23–27 oktober igen.
Två saker täcker den här sidan inte. Den första är leveransen – att mejlet hamnar i inkorgen och inte i skräpposten – som ägs av artikeln om att provskicka appens mejl. Den andra är långa jobb som bearbetar tusentals poster; de behöver delas upp, och där är Supabases rekommendation om högst 10 minuter per jobb en rimlig tumregel även i andra verktyg.
Spara de fyra proven som en rad i din provlista och kör om dem efter varje ändring som rör bokningarna eller utskicken. Ett schemalagt jobb bryts oftast av en ändring ingen kopplar till det: ett nytt fält för avbokning, en ny avsändaradress eller en omskriven beställning som skapar ett nytt jobb bredvid det gamla.
Klart när fyra prov ger facit och historiken finns
Arbetet är klart när prov 1 ger två mejl, prov 2 inga nya, prov 3 rätt svensk tid på båda sidor om 25 oktober och prov 4 ett besked om luckan utan dubbla påminnelser – och när du vet var historiken finns och har läst den måndag 26 oktober. Du behöver inte veta hur jobbet byggdes. Du behöver kunna visa att påminnelsen kommer en gång, klockan åtta.
Uppgifterna kontrollerades 25 september 2026: Lovable: Jobs, Replit: Deployment types (Scheduled), Supabase: Cron, Supabase: Cron quickstart och Förordning (2001:127) om sommartid. Funktioner och villkor kan ändras; kontrollera samma sidor när du gör proven.
Vem får besked när jobbet misslyckas? Vad händer om det körs två gånger? Och var läser jag körhistoriken måndag 26 oktober?