Hoppa till innehållet
Stackship-dokumentation English

FunktionerAnvändareMaskinöversatt

Timertriggrar

Hur en timerfunktions schema tolkas och körs — cron-formatet, tidszonen, överlappande och misslyckade körningar, och vad funktionen tar emot.

En timerfunktion körs enligt ett schema i stället för på en förfrågan. Den har ingen publik rutt, och autentisering gäller inte för den.

Schemats format

Ett schema är ett vanligt cron-uttryck med fem fält — minut, timme, dag i månaden, månad och veckodag:

Schema Körs
*/5 * * * * Var femte minut
0 * * * * Vid början av varje timme
0 7 * * 1-5 Klockan 07:00 UTC, måndag till fredag
30 2 1 * * Klockan 02:30 UTC den första dagen i varje månad

Det finns inget sekundfält. Ett uttryck som inte går att tolka avvisas när du sparar funktionen.

Tidszon

Alla scheman körs i UTC. Portalens fält Tidszon sparas inte, och funktionens Översikt visar alltid UTC. Skriv schemat i UTC: klockan 09:00 i Stockholm är 0 7 * * * på sommaren och 0 8 * * * på vintern.

Hur en körning går till

Funktionsnamnutrymmets proxy håller schemat. Vid varje schemalagd tidpunkt väcker den funktionen om den vilar, väntar upp till 30 sekunder på att den startar och anropar den sedan.

Vad en körning tar emot

En POST till /, med huvudena X-Stackship-Trigger-Type: timer och X-Stackship-Function-Name, och den här JSON-kroppen:

json
{
  "trigger": "timer",
  "functionName": "nightly-report",
  "scheduledTime": "2026-09-27T07:00:00.0012345Z",
  "schedule": "0 7 * * *"
}

scheduledTime är när proxyn startade körningen, i UTC. I en Node.js-hanterare är ctx.triggerType timer och req.body innehåller objektet ovan.

Överlappande körningar

En proxy väntar tills en körning är klar innan den räknar ut nästa tidpunkt, så när en körning pågår förbi nästa schemalagda tidpunkt hoppas den tidpunkten över och funktionen körs vid den därpå följande.

Viktigt

Varje funktionsnamnutrymmes proxy kör scheman för alla timerfunktioner i resursgruppen. Med fler än ett funktionsnamnutrymme i resursgruppen anropas funktionen en gång av var och en av dem vid varje schemalagd tidpunkt, och de körningarna överlappar. Lägg en timerfunktion i en resursgrupp med ett enda funktionsnamnutrymme, eller gör hanteraren säker att köra mer än en gång — se Hur en förfrågan når en funktion.

Fel och omförsök

En körning görs inte om. När hanteraren svarar med en felstatus, kör förbi tidsgränsen eller när funktionen inte startar inom 30 sekunder går proxyn vidare till nästa schemalagda tidpunkt. Utfallet visas inte i portalen: logga från din hanterare för att se varje körning i funktionens Loggar.

Missade körningar

Schemat finns i proxyns minne. Tidpunkter som passerar medan proxyn startar om körs inte i efterhand.

Tidsgräns

En körning har samma tidsgräns som ett HTTP-anrop, 300 sekunder — se Tidsgräns.

Vila mellan körningarna

Med standardvärdet minst 0 replikor vilar en timerfunktion tills dess första körning väcker den.

  • En timerfunktion som kör en egen avbild skalas ned till noll igen efter sin avkylningsperiod, som är 300 sekunder som standard, och väcks till nästa körning. Ett schema som körs oftare än avkylningsperioden håller den vaken.
  • En timerfunktion som byggs från portalen förblir vaken efter sin första körning — se Skala ned till noll.