WooCommerce Action Scheduler Kuyruğu Neden Birikiyor?

WooCommerce siparişleri oluşuyor, ancak planlı e-postalar gönderilmiyor, stok senkronizasyonu gecikiyor veya web kancaları saatlerce bekliyorsa Action Scheduler kuyruğunu kontrol etmeniz gerekir. Yönetim panelindeki görev sayısı yükselirken sunucu kaynakları normal görünebilir; çünkü sorun bazen çalışan işlemin CPU kullanımı değil, işlerin hiç tetiklenmemesi veya bir görevde uzun süre takılmasıdır.

Action Scheduler, WordPress eklentilerinin işleri hemen yapmak yerine ileri bir zamana planlamasını sağlayan bir görev kuyruğu kütüphanesidir. WooCommerce ve eklentileri bu yapıyı e-posta, stok, abonelik, web kancası ve dış servis senkronizasyonlarında kullanabilir. Kuyruğu düzeltmek için yalnızca cron aralığını kısaltmak yerine hangi aşamanın aksadığını bulmanız gerekir.

Action Scheduler kuyruğu nasıl çalışır?

Bir eklenti, örneğin bir siparişten sonra web kancası göndermek istediğinde Action Scheduler tablosuna bir action kaydeder. Kaydın hook adı, planlanan zamanı, durumu ve deneme bilgileri tutulur. Bir runner, yani görev işleyicisi, zamanı gelen kayıtları alır ve ilgili PHP callback’ini çalıştırır.

Bu işlem iki ayrı parçadan oluşur. İlk parça görevlerin kuyruğa yazılmasıdır. İkinci parça ise kayıtların seçilip çalıştırılmasıdır. Görevler doğru biçimde oluşuyor, fakat runner çalışmıyorsa pending, yani bekleyen kayıtlar artar. Runner çalışıyor, fakat callback hata veriyorsa failed, yani başarısız kayıtlar çoğalır.

Action Scheduler genellikle WordPress cron’u, siteye gelen isteklerle tetiklenen zamanlayıcılar veya WP-CLI gibi bir yöntem üzerinden çalıştırılabilir. WordPress cron gerçek bir işletim sistemi zamanlayıcısı değildir; çoğu kurulumda ziyaretçi isteği geldiğinde kontrol edilir. Düşük trafikli bir mağazada planlı görevlerin gecikmesinin nedeni bu olabilir.

WP-CLI ile çalışan bir kuyruk işçisi komut satırında ayrı bir PHP sürecidir. HTTP isteği yapmadığı sürece PHP-FPM web işçisi tüketmez. Bu ayrım önemlidir: Kuyruğu hızlandırmak için PHP-FPM çocuk süreçlerini artırmak, asıl sorun CLI cron’un çalışmamasıysa çözüm getirmez.

Biriken kuyruğun belirtileri ve anlamları

Pending sayısı sürekli yükseliyor

Pending görevlerin sayısı artıyor ve en eski planlanma zamanı geçmişte kalıyorsa runner yeterince sık çalışmıyor, görevleri yeterli hızda tüketemiyor veya bir görev grubu sürekli yeni işler üretiyor olabilir. Önce toplam sayıya değil, en eski görevin yaşına ve görevlerin hangi hook’larda toplandığına bakın.

Tek bir ürün senkronizasyonu veya web kancası hook’u yüzlerce bekleyen kayıt oluşturuyorsa sorun genel WooCommerce performansından çok ilgili entegrasyonda olabilir. Aynı görev başarısız olup yeniden planlanıyorsa kuyruk, işlenen hızdan daha hızlı büyür.

Failed görevleri artıyor

Failed kayıtlar, runner’ın en azından görevi denemeye başladığını gösterir; fakat callback başarıyla tamamlanmamıştır. Hata mesajında uzak API yanıtı, kimlik doğrulama, zaman aşımı, PHP istisnası veya veritabanı hatası bulunabilir. Sadece failed kayıtları silmek, hatanın sonraki siparişlerde yeniden oluşmasını engellemez.

Planlı e-postalar ve web kancaları gecikiyor

Action Scheduler e-postanın SMTP veya teslimat garantisini tek başına sağlamaz. Kuyruk görevi başarılı görünse bile mail sunucusu, DNS, alıcı politikası veya uygulama yapılandırması nedeniyle teslimat gecikebilir. Önce ilgili action’ın çalışıp çalışmadığını, ardından e-posta katmanını inceleyin. E-posta teslim zincirini ayrıca değerlendirmek için WooCommerce transactional e-posta altyapısı konusunu kullanabilirsiniz.

Yönetim paneli yavaşlıyor veya zaman aşımına uğruyor

Scheduled Actions ekranı çok sayıda kayıtla çalışırken sorgu ve sayfalama yükü oluşturabilir. Bu durum doğrudan tüm mağazanın yavaş olduğu anlamına gelmez. Panel sorguları ağırsa görevleri panelden topluca çalıştırmak yerine komut satırında kontrollü batch boyutlarıyla ilerlemek daha güvenlidir.

Önce teşhis: Hangi tür görev birikiyor?

Veri değiştiren bir temizlik veya yeniden deneme işlemine geçmeden önce veritabanı yedeği alın ve mümkünse son geri dönüş noktasını doğrulayın. Canlı mağazada stok, sipariş ve ödeme süreçlerini etkileyebilecek görevlerde bakım zaman aralığı belirleyin. Teşhis için görevi silmek veya hook’u devre dışı bırakmak gerekmez.

Yönetim panelinden ilk kontrol

WooCommerce veya WordPress yönetim alanında Scheduled Actions ekranını açın. Pending, in-progress, complete, failed ve canceled durumlarını ayrı inceleyin. Aşağıdaki sorular hızlı bir sınıflandırma sağlar:

• En eski pending görevin planlanan zamanı ne kadar geçmiş?
• Bekleyen görevler tek bir hook altında mı, yoksa birçok eklentiye mi dağılmış?
• Failed kayıtlarında aynı hata veya aynı dış servis tekrarlanıyor mu?
• Görevler çalışıyor fakat yeni görevler daha hızlı mı ekleniyor?
• Bir görevin argümanları aynı nesne veya sipariş için tekrar tekrar mı oluşuyor?

Panelde bir görevi elle çalıştırmadan önce hook adını ve sağlayan eklentiyi not edin. Özellikle stok, ücret iadesi, abonelik ve web kancası görevleri yan etki yaratabilir; aynı işi bilinçsizce tekrar çalıştırmak dış sisteme yinelenen bildirim gönderebilir.

WP-CLI ile durum ve zaman kontrolü

SSH erişiminiz, doğru WordPress kurulum yolu ve site kullanıcısının gerekli dosya izinleri varsa WP-CLI ile daha ayrıntılı çıktı alabilirsiniz. Aşağıdaki komutlar listeleme ve WordPress cron durumunu kontrol etme amaçlıdır:

cd /var/www/example.com
wp action-scheduler list --status=pending --per-page=20
wp action-scheduler list --status=failed --per-page=20
wp cron event list

Buradaki yol örnektir; kendi WordPress kurulum dizininizi kullanın. Komutun bulunmaması Action Scheduler’ın eski bir sürümünü, WP-CLI uzantısının etkin olmamasını veya farklı bir komut adını gösterebilir. Önce eklenti ve WP-CLI sürümlerini doğrulayın; rastgele bir eklentiyi kaldırarak çözüm aramayın.

Pending listesinde planlanan zaman, hook ve grup bilgilerini; failed listesinde hata ayrıntılarını karşılaştırın. Aynı hook’un her çalıştırmada yeni kayıt üretip üretmediğini de gözlemleyin. Bu gözlem, tetikleme sorunu ile callback sorunu arasındaki farkı belirler.

Action Scheduler kuyruğu neden birikir?

WP-Cron veya sunucu cron’u çalışmıyordur

WordPress cron’u devre dışı bırakılmış olabilir. Bazı yöneticiler WP-Cron’un ziyaretçi isteğine bağlı davranışını önlemek için wp-config.php içinde DISABLE_WP_CRON kullanır. Bu tercih, yerine işletim sistemi cron’u tanımlanmadıysa Action Scheduler dahil planlı işlerin durmasına yol açar.

Sunucu cron’u tanımlı olsa bile yanlış PHP binary’si, yanlış WordPress yolu, farklı kullanıcı izinleri veya çalışma dizini nedeniyle komut başarısız olabilir. Cron çıktısını ve sistem loglarını kontrol etmeden aralığı sıklaştırmayın.

Loopback veya HTTP çağrısı engelleniyordur

Web tabanlı runner, aynı siteye loopback adı verilen iç HTTP isteği gönderebilir. Güvenlik eklentisi, temel kimlik doğrulama, WAF, DNS çözümlemesi, TLS doğrulaması veya sunucu kuralı bu isteği engellerse panel normal görünse bile görevler çalışmayabilir. WordPress Site Health içindeki loopback uyarısını ve web sunucusu erişim loglarını birlikte inceleyin.

İzleme uç noktasını etkinleştirmek ile web sunucusunda bu uç noktaya güvenli erişim yolu tanımlamak ayrı işlemlerdir. Bir endpoint’i açmak, onu herkese açık bırakmayı gerektirmez. Erişim gerekiyorsa yalnızca uygun yöntem, kimlik doğrulama ve ağ kuralı ile sınırlandırın.

Bir callback uzun sürüyor veya kilitleniyordur

Bir görev dış API’den yanıt bekliyor, büyük bir ürün grubunu tek işlemde güncelliyor veya veritabanında kilit bekliyorsa worker batch içindeki diğer işlere geçemeyebilir. PHP max_execution_time, HTTP timeout ve uzak servisin yanıt süresi burada etkili olabilir. Teşhis sırasında bu ayarları topluca değiştirmek yerine hangi hook’un süreyi tükettiğini belirleyin.

Üretim hızı tüketim hızını geçiyordur

Stok senkronizasyonu, fiyat güncellemesi veya pazaryeri aktarımı düzenli aralıklarla yeni işler oluşturur. Runner çalışsa bile her çalıştırmada tüketilen görev sayısı, aynı zaman aralığında üretilen görev sayısından düşükse kuyruk büyür. Bu durumda yalnızca daha sık cron çalıştırmak, dış servis limitlerine veya veritabanı yüküne çarparak yeni bir sorun oluşturabilir.

Veritabanı ve sunucu kapasitesi sınırdadır

Action Scheduler tablolarında çok sayıda kayıt bulunması, sorguların ve temizlik işlerinin maliyetini artırabilir. Disk doluluğu, inode sınırı, yüksek I/O beklemesi, düşük veritabanı bağlantı kapasitesi veya PHP süreç sınırı da runner’ın görevleri zamanında bitirmesini engeller. WooCommerce kapasite planlama yaklaşımıyla CPU, RAM, disk I/O ve veritabanı davranışını birlikte değerlendirin; tek bir metriğe göre karar vermeyin.

Dar kapsamlı düzeltme nasıl yapılır?

Cron tetikleyicisini düzeltin

Ön koşul olarak site yolunu, PHP sürümünü, WordPress kullanıcısını ve yedek durumunu doğrulayın. WP-Cron devre dışıysa sistem yöneticinizle gerçek cron’un kurulu olup olmadığını kontrol edin. Cron komutunu önce elle, sınırlı bir gözlem için çalıştırın:

cd /var/www/example.com
wp cron event run --due-now

Bu komut due, yani zamanı gelmiş WordPress cron olaylarını çalıştırır. Action Scheduler sürümünüz kendi runner’ını WP-Cron üzerinden kullanıyorsa etkisini gözlemleyebilirsiniz. Komut hata verirse hata metnini çözmeden tekrar tekrar çalıştırmayın.

WP-CLI ile doğrudan Action Scheduler çalıştırmak için kurulu sürümün desteklediği komutu kullanabilirsiniz:

cd /var/www/example.com
wp action-scheduler run --batch-size=20 --batches=1

Buradaki düşük batch boyutu ve tek batch, önce kontrollü doğrulama içindir. Kurulu sürümünüz bu seçenekleri desteklemiyorsa wp action-scheduler help run çıktısını esas alın. Çalıştırma sonrasında pending sayısını, en eski görevin yaşını ve failed kayıtlarını yeniden kontrol edin.

Pending sayısı azalıyor ve hata oranı değişmiyorsa tetikleme sorunu büyük ölçüde doğrulanmıştır. Ardından cron’u uygun aralıkta kalıcılaştırın. Sadece daha kısa aralık belirlemek yerine işlem süresi, dış API limitleri ve sunucu kapasitesiyle uyumlu bir periyot seçin.

Başarısız hook’u izole edin

Failed kaydındaki hook ve hata mesajı aynı ise önce bu görevi sağlayan eklentinin güncel sürümünü, API kimlik bilgilerini ve dış servis durumunu kontrol edin. Eklentiyi canlı sipariş akışı üzerinde kapatmadan önce staging ortamında veya bakım penceresinde test edin. Sorun yalnızca tek bir entegrasyondaysa tüm Action Scheduler kuyruğunu durdurmak yerine ilgili entegrasyonun ayarını düzeltin.

Hata bir uzak API zaman aşımıysa yeniden deneme sayısını kontrol edin. Her denemede aynı isteğin dış sisteme ulaşıp ulaşmadığını ve idempotency, yani aynı isteğin tekrarında yinelenen yan etki oluşturmama desteğini doğrulayın. Bu bilgi yoksa toplu retry işlemi ödeme, stok veya sipariş bildirimlerinde tekrar yaratabilir.

Tüketim hızını kontrollü artırın

Runner çalışıyor, fakat bekleyen görevler yavaş azalıyorsa önce küçük bir batch ile sunucu etkisini ölçün. CPU, RAM, disk I/O, veritabanı sorgu süresi ve PHP süreçlerini izleyin. Ardından batch boyutunu kademeli değiştirin; aynı anda çok sayıda paralel worker başlatmak kilit çakışması ve dış servis rate limit’i oluşturabilir.

Web istekleriyle çalışan runner için PHP-FPM çocuk süreçleri önemlidir. Ancak CLI üzerinden çalışan cron veya kuyruk işçisi FPM havuzunu tüketmez; kendi PHP sürecini kullanır. Bu nedenle FPM ayarlarını değiştirmeden önce işin gerçekten HTTP üzerinden mi, CLI üzerinden mi çalıştığını belirleyin. Web trafiği de yavaşlıyorsa PHP-FPM ayarları ayrıca incelenebilir.

Eski kayıtlar nasıl temizlenir?

Complete ve canceled kayıtların tutulma süresi eklenti sürümüne ve mağazanın operasyonel ihtiyacına göre değişebilir. Önce veritabanı yedeğinin geri yüklenebilir olduğunu doğrulayın. Ardından Action Scheduler’ın kendi cleanup davranışının çalışıp çalışmadığını ve cron loglarında temizlik görevi bulunup bulunmadığını kontrol edin.

Temizlik, pending veya failed işlerin çözümü değildir. Başarısız görevleri arşivlemek ya da silmek yerine, hata kaynağı ortadan kalktıktan sonra güvenli olanları yeniden planlayın. Sipariş ve stokla ilişkili görevlerde ilgili nesnenin güncel durumunu karşılaştırmadan toplu işlem yapmayın.

Tablolar büyümüşse veritabanı disk alanını, indeks kullanımını ve sorgu sürelerini inceleyin. Yalnızca tabloyu optimize etmek, her gün yeni görev üreten hatalı entegrasyonu çözmez. Önce üretim nedenini, sonra geçmiş kayıtların yaşam döngüsünü düzeltin.

Değişikliğin işe yaradığını nasıl doğrularsınız?

Bir düzeltmeden sonra üç farklı zaman diliminde ölçüm yapın: hemen sonrasında, normal trafik sırasında ve bir planlı görev döngüsünün ardından. Şu göstergeleri karşılaştırın:

• En eski pending görevin yaşı azalıyor mu?
• Yeni üretilen görev sayısı, tamamlanan görev sayısından düşük mü?
• Failed görevlerde aynı hook ve hata tekrarlanıyor mu?
• Planlı e-posta, stok veya web kancası çıktısı ilgili sistemde doğrulanıyor mu?
• Runner çalışırken web yanıt süreleri, veritabanı yükü veya PHP süreçleri kabul edilebilir mi?

Bir action’ın complete olması, dış sistemin işlemi kabul ettiğini her zaman kanıtlamaz. Örneğin web kancası isteği HTTP seviyesinde başarılı dönmüş olabilir, ancak karşı sistem uygulama seviyesinde reddetmiş olabilir. Bu nedenle Action Scheduler durumunu, eklenti loglarını ve karşı servisin yanıtını birlikte değerlendirin.

Sık Sorulan Sorular

Action Scheduler kuyruğunu elle çalıştırmak güvenli mi?

Görevin yan etkisi ve eklentinin tekrar çalıştırma davranışı biliniyorsa, küçük bir batch ile kontrollü çalıştırma yapılabilir. Ödeme, stok ve web kancası görevlerinde önce yedek, log ve dış sistem tekrar politikası doğrulanmalıdır.

Pending görev sayısı yüksekse site mutlaka yavaşlar mı?

Hayır. Kuyruk sayısı tek başına web performansını göstermez. Asıl etki; sorgu maliyeti, runner’ın çalışma biçimi, görevlerin süresi, disk ve veritabanı kaynakları ile web trafiğinin aynı kaynakları kullanıp kullanmamasına bağlıdır.

WP-Cron’u tamamen kapatmak doğru mudur?

Trafiğe bağlı tetiklemeyi azaltmak için gerçek bir sunucu cron’u kuruluysa tercih edilebilir. Ancak cron’u kapatmadan önce WordPress cron olaylarının ve Action Scheduler runner’ının yeni yöntemle gerçekten çalıştığını doğrulayın.

Başarısız görevleri yeniden denemeden önce neye bakmalıyım?

Hata mesajına, hook’u sağlayan eklentiye, görevin argümanlarına ve dış sistemde aynı işlemin gerçekleşip gerçekleşmediğine bakın. Sorun çözülmeden yapılan toplu yeniden deneme, aynı bildirimi veya stok değişikliğini tekrarlayabilir.

Uygulanabilir kontrol listesi

• Pending, failed ve complete durumlarını ayrı listeleyin.
• En eski bekleyen görevin zamanını ve en sık tekrarlanan hook’u not edin.
• WP-Cron, sunucu cron’u ve loopback davranışını ayrı ayrı doğrulayın.
• Callback hatasını, dış API yanıtını ve eklenti logunu karşılaştırın.
• Yedek ve geri dönüş planı olmadan görevleri veritabanından silmeyin.
• Önce küçük batch ile test edin; ardından kaynak kullanımını izleyerek kademeli artırın.
• Değişiklik sonrasında kuyruğun yaşını, hata oranını ve gerçek çıktıyı yeniden kontrol edin.

İlk sonraki adımınız, panelden en eski pending ve failed görevlerin hook adlarını çıkarmak olmalı. Tek bir hook baskınsa o eklentinin callback’ini ve entegrasyonunu inceleyin; tüm görevler bekliyorsa cron ve loopback teşhisine geçin. Böylece WooCommerce Action Scheduler kuyruğu için genel bir ayar değişikliği yerine, gözlenen arızaya uygun dar bir düzeltme uygulayabilirsiniz.