Vercel Schedules, Cron Jobs'un saat dilimi farkındalıklı halefi olarak açık betaya adım attı

Vercel, Cron Jobs'un halefi Schedules'ı kullanıma sundu

dev.to'da yayımlanan bir yazıya göre Vercel, Schedules'ı 4 Kasım 2026'da tanıttı ve bir gün sonra açık beta ilan etti. Schedules, Cron Jobs'un halefi olarak konumlandırılıyor; ancak geçiş isteğe bağlı: mevcut cron yapılandırmaları çalışmaya devam ediyor ve Vercel, zorunlu bir geçiş yerine bir migrasyon rehberi sunuyor.

Vercel üzerindeki Cron Jobs fiilen bir yol artı UTC üzerinden değerlendirilen bir cron ifadesiydi. Schedules ise statik yapılandırmayı vercel.json'da (veya Build Output API'de) koruyor ve @vercel/schedules SDK, CLI ve API üzerinden bir runtime katmanı ekliyor; böylece schedule'lar yeniden dağıtım yapmadan oluşturulabiliyor, iptal edilebiliyor, açılıp kapatılabiliyor veya talep üzerine tetiklenebiliyor.

Yeni olan ne

dev.to karşılaştırmasına göre önemli farklar şunlar:

• Saat dilimleri. Her schedule bir IANA saat dilimi kabul ediyor; cron'lar yalnızca UTC ile çalışıyordu.
• Özel hedefler. Bir schedule, schedule/v1beta türünde bir experimentalTriggers girdisi aracılığıyla bir fonksiyonu tetikleyebiliyor. Bu fonksiyonun herkese açık bir URL'si yok ve yalnızca scheduler tarafından çağrılabiliyor; paylaşılan gizli anahtar gibi bir koruma eklemediğiniz sürece herkese açık şekilde erişilebilen cron yol isteklerinin aksine.
• HTTP metodu. Yol tabanlı schedule'lar varsayılan olarak POST kullanıyor, oysa Cron Jobs GET istekleri gönderiyordu. Olduğu gibi taşınan handler'ların requestMethod değerinin GET olarak ayarlanması gerekiyor.
• Preview güvenliği. Yeni statik schedule'lar Preview dağıtımlarında pasif başlıyor; böylece bir branch'e push yapmak yanlışlıkla production işlerini tetiklemiyor.
• Dinamik planlama. Runtime'da oluşturulan tek seferlik veya yinelenen schedule'lar Queue topic'lerini hedefleyebiliyor ve bir payload taşıyabiliyor; makale bunu, örneğin bir fonksiyonu açık tutmadan saatler önce bir agent takibini planlamak gibi, polling desenlerinin yerine geçen bir çözüm olarak çerçeveliyor.

Teslim en az bir kez (at-least-once) biçiminde: kopyalar mümkün, fonksiyon veya yol hedefleri için otomatik yeniden deneme yok (yeniden denemeler kuyruk tarafında geçerli) ve handler'ların execution ID üzerinden tekilleştirme (deduplication) yapması gerekiyor. Payload'lar 16 KB ile sınırlı ve çalıştırma geçmişi 90 gün saklanıyor.

Fiyatlandırma ve limitler

Aşağıdaki rakamlar Vercel'in changelog ve limit sayfalarından dev.to yazarı tarafından 6 Kasım 2026'da okunan değerlerdir ve makale, bunların bir faturalandırma garantisi değil bir anlık görüntü olduğunu vurguluyor:

• Pro ve Enterprise, plana dahil miktarın ötesinde her 1 milyon çalıştırma için 5 dolar ve her 1 milyon schedule oluşturma için 10 dolar üzerinden ölçülüyor.

• Hobby aylık 500 oluşturma ve 5.000 çalıştırma içeriyor; bunları aşan durumlarda her ikisi de bir sonraki faturalandırma dönemine kadar engelleniyor.

• Takım limitleri Hobby'de 1.000, Pro'da 10.000 ve Enterprise'ta 100.000 schedule; Hobby dağıtımı başına ise en fazla 100 statik schedule.

• Hobby schedule'ları 15 dakikalık bir jitter penceresi içinde en fazla 15 dakikada bir tetikleniyor. Pro ve Enterprise varsayılan olarak 1 dakikalık pencere kullanıyor ve 1 ile 15 dakika arasında yapılandırılabiliyor.

• Karşılaştırma gerekirse, Hobby Cron Jobs günde en fazla bir kez saat hassasiyetiyle çalışıyor; Pro ve Enterprise cron'ları dakikada bir kez kadar sık çalışabiliyor ve cron'lar fonksiyon çağrısı olarak faturalandırılmaya devam ediyor.

İki kez tetiklemeden migrasyon

dev.to kontrol listesi, crons dizisinin tek bir dağıtımda adlandırılmış schedules girdileriyle değiştirilmesini, handler'ların hâlâ GET beklediği yerlerde requestMethod'un GET olarak ayarlanmasını ve cron girdilerinin aynı değişiklikte silinmesini öneriyor — ikisi de yapılandırılmış halde kalırsa aynı iş iki kez çalıştırılır. Dağıtımdan sonra schedule'ı dashboard'un Schedules sekmesinde doğrulayın ve CLI üzerinden elle tetikleyin, ardından isteğe bağlı olarak yol hedeflerini özel fonksiyonlara taşıyarak açık yüzeyi daraltın.

Neden önemli

Schedules, uzun süredir devam eden birkaç serverless sıkıntısını tek seferde ortadan kaldırıyor: UTC aritmetiği olmadan saat dilimi farkındalıklı tetikleyiciler, gizli anahtarlarla korunan herkese açık uç noktalar yerine özel çağırma ve artık dağıtımlara bağlı olmayan runtime kontrolü. Ölçümlü fiyatlandırma ayrıca maliyet tartışmasını fonksiyon çağrısı faturalandırmasından çalıştırma başına ve oluşturma başına ücretlere kaydırıyor; bu yüzden yüksek frekanslı iş yükleri her ikisini de modellemeli. Migrasyonun kendisi çoğunlukla bir yapılandırma yeniden şekillendirme olsa da, varsayılan POST'a geçişi taşınan GET handler'ları için sessiz bir kırıcı ve en az bir kez teslim, idempotent handler'ları iyi bir uygulama olmaktan çıkarıp zorunlu bir gereklilik hâline getiriyor.