예약 실행

runlot.json 에 triggers 를 더하면 워커의 scheduled 핸들러가 적어 둔 시각에 돕니다.

{
  "name": "my-app",
  "main": "src/index.ts",
  "triggers": { "crons": ["30 18 * * *"] }
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    return new Response("hello");
  },
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    // controller.scheduledTime 은 지금이 아니라 이 실행의 **예정 시각**입니다.
    // controller.cron 은 발화한 표현식입니다.
    await rebuild(env);
  },
};

runlot deploy 는 등록할 스케줄을 찍어 줍니다. 돌기 전에 확인하세요.

예약 실행 (UTC): 30 18 * * *

표현식

다섯 칸입니다. 분 시 일 월 요일, 시간대는 UTC 입니다.

일요일은 0 입니다 (7 도 받습니다). 일과 요일이 둘 다 제한돼 있으면 둘 중 하나만 맞아도 돕니다 — cron 이 원래 그렇게 동작하므로, 0 0 1 * 1 은 "매월 1 일, 또는 매주 월요일" 입니다.

표현식은 배포할 때 실제로 해석합니다. 문법이 틀렸거나 영영 발화하지 않는 것(0 0 30 2 * — 2 월 30 일)은 어느 칸이 문제인지와 함께 400 으로 거절합니다. 받아 주고 안 도는 스케줄은 배포가 깨진 것과 구별되지 않기 때문입니다.

한도

상한을 넘긴 실행은 취소하고 실패로 기록합니다. 자주 도는 스케줄의 예산을 작게 잡은 것은 의도입니다 — 비용이 드는 것은 스케줄을 하나 더 가진 것이 아니라 2 분마다 프로젝트를 깨우는 것입니다.

알아 두실 것

시각은 근사값입니다. 실행은 적어 둔 분에, 또는 그 뒤에 시작합니다. 정확한 초에 기대는 것은 만들지 마세요.

앞 실행이 안 끝났으면 다음 회차는 건너뜁니다. 2 분마다 도는 작업이 3 분을 쓰면 그 사이에 온 회차는 건너뛰고 로그에 남깁니다. 이 규칙이 없으면 차선이 하나뿐인 프로젝트에 일이 쌓이기만 합니다.

많이 밀린 실행은 버립니다. 한동안 서빙되지 않았다면 밀린 것을 전부 따라잡는 대신 가장 최근 회차만 한 번 돌립니다. 그러지 않으면 한 시간의 정전이 */2 * * * * 를 30 번 연달아 쏘게 합니다.

주차된 프로젝트는 깨웁니다. 프로젝트는 쉬는 동안 프로세스를 내립니다(멈춤과 재개). 스케줄이 먼저 깨우고 그다음 돕니다. 깨우는 시간이 실행에 포함되므로, 쉬고 있던 프로젝트의 첫 실행은 수백 밀리초 더 걸립니다.

콜드 상태의 프로젝트는 늦게 돕니다. 오래 쉬면 데이터가 기계 밖으로 옮겨질 수 있습니다(콜드 상태와 재개). 지금은 스케줄이 그것을 다시 끌어오지 않습니다 — 다른 무언가가 프로젝트를 되살린 뒤에 돕니다. 그 프로젝트를 건드리는 것이 스케줄뿐이라면 한 시간 이하 주기로 두세요.

확인하기

성공했든 건너뛰었든 실패했든, 실행마다 프로젝트 로그에 한 줄이 남습니다.

runlot logs

[runlot] 예약 실행 30 18 * * * 를 마쳤습니다 (1.2s)

워커가 scheduled 를 내보내지 않으면 실행은 실패로 기록되고 그 이유가 같은 자리에 남습니다. main 없이 triggers 만 적은 배포는 거절합니다 — 정적 자산만 있는 배포에는 부를 핸들러가 없습니다.

바꾸거나 없애기

스케줄은 코드와 같이 움직입니다. runlot.json 을 고쳐 배포하세요. 옛 버전으로 되돌리면 그 버전의 스케줄로 같이 돌아갑니다. triggers 를 지우고 배포하면 멈춥니다.

아직 없는 것

손으로 한 번 돌리는 길과, 로그 버퍼 너머의 실행 이력은 없습니다. 원할 때 시작해야 하는 작업은 경로를 하나 열고 runlot secret set 으로 넣은 토큰으로 지키세요.