封面圖片：哪些工作排程器能準時觸發？我們測試了十款。

Mike Gorman

我們為 smplkit 打造的應用基礎設施產品之一，是一個名為 Smpl Jobs 的 HTTP 工作排程器。當然，我們希望它在與其他工作排程器競爭時能表現優異，但我們想知道它在最重要的功能——準時發出 HTTP 請求——方面的實際表現如何。因此，我們決定找出答案。

參賽者

測試設定

測試概念很簡單：在整點發送請求到某個公開端點，並記錄請求到達的日期與時間。超過整點的毫秒數即為偏移量（skew）：偏移量越低，表示排程器越「準時」。

雖然概念簡單，但要找到一個公開端點，讓排程器可以觸發，同時又能捕捉並儲存到達時間，其實並不容易。我們最終需要的是一個通用基準測試託管網站，能夠 POST JSON 訊息，用來識別基準測試、測試對象，並記錄請求到達的日期與時間。我們找不到符合需求的服務，因此自己建了一個。三週後，smplmark.org 上線，準備接受各排程器的測試。

我們建立基準測試，定義測試對象，然後將每個排程器設定為在 smplmark 的 measurement API 發出請求，並附上 JSON 酬載，識別基準測試、執行次數，以及正在測試的排程器 ID。smplmark 會記錄每次測量建立的日期與時間；另一個 skew 指標則由 created_at mod 3600000 衍生而來，代表超過整點的毫秒數。

每位參賽者皆使用免費方案（或接近免費方案）：其中有幾個每月大約會向我們收取一美元的費用。部分原因是為了維持公平性；主要目的是將帳單維持在接近零的程度。

為什麼我建立 smplmark.org

幾個缺點

我們已知的測試方法有四個缺點：

  1. 偏移量是以小時為模數計算，因此如果排程器剛好晚了 60.1 分鐘，實際上會顯示為只晚了 6 秒。這是極端案例：唯一晚到足以接近這個邊界的參賽者是 GitHub Actions，而它們是以分鐘級的差距落後，而不是以秒為單位。這個模數計算也會反向作用：如果請求提早到達，會被記錄為接近一小時晚。但所有接近這個邊界的到達時間都屬於 GitHub Actions，而它們的不穩定性是顯而易見的（且有文件記載）。
  2. 端點位於美國東部，因此在美國西部或歐洲執行的排程器會比美國東部的排程器多負擔網路延遲。但這只有幾毫秒；排程器的引擎本身才是主要影響因素。
  3. smplmark.org 本身運行在 Cloudflare 上，因此 Cloudflare Workers 可能享有主場優勢；它的請求可能從未離開 Cloudflare 的網路。
  4. 偏移量依賴 smplmark 的時鐘。smplmark 運行在 Cloudflare 上，其時鐘與 NTP 同步；我們沒有獨立驗證這些時鐘。如果時鐘發生偏移，每個測試對象都會偏移相同的量——排序會維持不變，但絕對數值不會。排程器自身的時鐘不會被校正：當你的時鐘顯示到達時間時才觸發，這正是我們要測量的內容。

排行榜

以下是目前的測試結果。以下圖片為固定快照，因此我們引用的數字會與其來源圖表並列；即時排行榜每小時更新一次，當你閱讀本文時，數字可能已經改變。我們從圖表中移除了 GitHub Actions，因為在其規模下，其他長條將無法顯示。

即時長條圖：以毫秒為單位的排程器偏移量中位數，每個排程器一條長條，由低到高排序，已排除 GitHub Actions 以符合比例

截至 7 月 31 日，整點過後的偏移量中位數（毫秒）。開啟即時排行榜查看最新數字與測試方法。

數據說明

Posthook 最接近目標，中位數偏移量為 656 毫秒，緊隨其後的是 Runhooks 的 749 毫秒。QStash 與 Smpl Jobs 旗鼓相當，約為 1.5 秒；在其後，EasyCron、Google Cloud Scheduler 與 cron-job.org 皆穩定地在要求時間的約 4 到 8 秒 內觸發。

排程器偏移量折線圖：每條線代表一個排程器（已排除 GitHub Actions 以符合比例）：最緊密的線條緊貼零值，數條線位於標記上方數秒，一條平坦線位於約 26,500 毫秒，另一條線則維持在約 33,000 毫秒，最後幾小時跳升至約 51,000 毫秒

截至 7 月 31 日上午的四天到達記錄，每個到達時間一個點，已排除 GitHub Actions 以符合比例。

有趣的是，AWS EventBridge 幾乎總是準確地晚了 26.5 秒。我們記錄的每一次到達時間都落在幾百毫秒的範圍內；你可以根據它到底晚了多久來對錶。公平來說，EventBridge 的設計目的是在大規模下分發事件，而且它擅長這件事。

Cloudflare Workers 也持續延遲：通常在整點過後約 33 秒——雖然本週有幾次執行漂移到接近 51 秒。我們原本以為其請求可能不會離開自身網路的參賽者，仍然晚了 33 秒，因此對它們來說並沒有主場優勢。

排程器偏移量統計表（毫秒）：平均值、中位數、最小值、最大值、p95、p99 以及每次執行的次數，每個排程器依中位數排序

截至 7 月 31 日，包含 GitHub Actions 在內的所有排程器的最小值、最大值與百分位數。單位仍為毫秒。

GitHub Actions 的中位數偏移量約為 27 分鐘，這已經是寬鬆的估計。超過一半的時間，GitHub Actions 甚至沒有觸發。公平來說，GitHub 已經告訴你這件事：排定的工作流程文件說明為「盡力而為」，在負載高時會延遲或被丟棄。他們沒有錯。你不必只相信我們的話：[我們使用的 workflow 是公開的（https://github.com/smplkit/benchmarks/actions/workflows/cron-skew.yml），而 GitHub 自己的執行記錄就在其 Actions 分頁上——包括那些工作流程根本沒有執行的每小時空白。

我們不是第一名——我們可以接受

當我們看到自己排程器的數字持續晚約 1.5 秒時，我們分析了程式碼，看看有沒有優化的空間。我們曾考慮讓它提早一點啟動；如果我們總是晚 1.5 秒，為什麼不提早 1.4 秒啟動呢？但我們並非「總是」晚 1.5 秒。「提早啟動」的策略導致我們有時會提早幾毫秒觸發，我們認為這可能比晚 1.5 秒還要「糟糕」。因此，我們取消了提早啟動的設定，決定讓結果自然呈現。我們會繼續努力改善我們的數字，但在此同時，只有 Posthook 最差的一次執行比我們最差的一次執行還要差，所以情況還算不錯。

但不要只相信我們的話

我知道，我知道。一個由 smplkit 建立的基準測試，結果託管在 smplkit 建立的網站上，恰好顯示 Smpl Jobs 是「準時」工作排程器中的佼佼者之一。我們知道這看起來如何。但這正是我們建立 smplmark.org 的原因。世界上任何人都可以建立帳戶
並做我們所做的事。如果需要協助，請寄信至 [email protected]。

你應該在意嗎？

任何能在預定時間的幾秒內觸發的工作排程器，對大多數團隊來說可能就足夠了。我們測試的 10 個排程器中有 9 個會在預定時間的 60 秒 內觸發，其中 7 個會在 10 秒 內觸發。但如果追求最準時的執行，Posthook、Runhooks、Smpl Jobs 與 QStash 通常都會在要求時間的幾秒內觸發。

但「準時到秒」只是考量之一。如果你在意回應擷取、執行歷史、時區、重試政策與 SDK，請查看 2026 年最佳 cron 工作服務。