Django Celery Beat ile Zamanlanmış Görevler

Django Admin'de periyodik görev kaydetmek, işin çalıştığını göstermez. Beat zamanı gelen görevi kuyruğa gönderir; broker mesajı taşır, worker ise Python fonksiyonunu çalıştırır. Bu üç halkadan biri eksikse zamanlama doğru görünse bile rapor üretilmez veya temizlik yapılmaz.

Bu rehber, mevcut Django projesine Celery ve django-celery-beat ekleyerek uçtan uca doğrulanabilir bir kurulum yapmanız içindir. Önce oturumları sayan zararsız bir görev çalıştıracak, sonra veritabanında zamanlama oluşturacaksınız. Yalnızca günde bir yönetim komutuna ihtiyacınız varsa Python cron yaklaşımı daha az bileşen gerektirebilir; Celery'yi kuyruk ve worker ihtiyacınızla birlikte değerlendirin.

Benzer mimariyi Rails ile kuruyorsanız Rails uygulamalarında cron ve görev zamanlama seçenekleri rehberindeki sistem cron'u ile uygulama içi zamanlayıcı ayrımını da inceleyin.

Celery, Beat ve DatabaseScheduler Nasıl Çalışır?

Celery bir görev kuyruğu sistemidir. Redis veya RabbitMQ gibi bir broker görev mesajlarını worker'lara iletir. Beat bir zamanlayıcı sürecidir; görevleri kendisi yürütmez. django-celery-beat ise zamanlamayı Django veritabanında saklayan ve Admin üzerinden düzenlemeye açan eklentidir. DatabaseScheduler ayarı, Beat'in bu kayıtları okumasını sağlar.

Aynı zamanlama kümesi için yalnızca bir Beat çalıştırın. Ortak veritabanı kullanmak iki Beat'i kendiliğinden birbirinden haberdar etmez; ikisi de mesaj yayımlayabilir. Worker sayısını ise ihtiyaca göre artırabilirsiniz. Bileşenlerin görevleri ve tek zamanlayıcı gereği Celery periyodik görev belgesinde açıklanır.

Adım Adım Kurulum ve Django Bağlantısı

Kurulumun güvenilir sırası; bağımlılıkları ve Celery uygulamasını hazırlamak, django_celery_beat geçişlerini uygulamak, ardından worker ile Beat'i ayrı süreçlerde başlatmaktır. Önce tek bir zararsız görevi uçtan uca çalıştırmadan üretim zamanlamalarını eklemeyin.

Örneklerde proje paketi proje, uygulama paketi uygulama adını taşır. Siz kendi Python paket adlarınızı kullanın. Django kurulu, migrations uygulanmış ve uygulama INSTALLED_APPS listesinde olmalıdır. Oturum örnekleri Django'nun veritabanı oturum altyapısını kullanır; signed cookie gibi başka bir oturum motorunda aynı rapor anlamlı değildir.

1. Projenin sanal ortamını etkinleştirin. Django, Python, Celery ve eklentinin desteklediği sürümleri birlikte kontrol edin; paket sürümlerini projenizin bağımlılık dosyasında sabitleyin.
2. Celery ve Redis istemcisini kurun. Bu komut Redis sunucusu kurmaz; ayrıca erişilebilir bir broker hazırlamanız gerekir.
3. Celery uygulamasını oluşturup Django ayarlarını CELERY önekiyle yükleyin. Görev keşfi için uygulamanızın tasks.py dosyası kullanılacaktır.
4. django_celery_beat uygulamasını mevcut INSTALLED_APPS listesine ekleyin ve veritabanı geçişlerini çalıştırın.

python -m pip install "celery[redis]" django-celery-beat
python -m django --version
python -m celery --version

# proje/celery.py
import os
from celery import Celery

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "proje.settings")
app = Celery("proje")
app.config_from_object("django.conf:settings", namespace="CELERY")
app.autodiscover_tasks()

# proje/__init__.py
from .celery import app as celery_app

__all__ = ("celery_app",)

# proje/settings.py; mevcut ayarlara ekleyin
import os

INSTALLED_APPS += ["django_celery_beat"]

CELERY_BROKER_URL = os.environ["CELERY_BROKER_URL"]
CELERY_TIMEZONE = "Europe/Istanbul"
CELERY_ENABLE_UTC = True
CELERY_BEAT_SCHEDULER = "django_celery_beat.schedulers:DatabaseScheduler"
USE_TZ = True
TIME_ZONE = "Europe/Istanbul"

# Linux geliştirme ortamı; yerel Redis sunucusu çalışıyor olmalı
export CELERY_BROKER_URL=redis://127.0.0.1:6379/0
python manage.py migrate
python manage.py check

Worker, Beat ve Django web süreci aynı broker ve veritabanı ayarlarına erişmelidir. Container içinde localhost başka bir container'ı göstermez; Compose ağında Redis servis adını kullanmanız gerekebilir. Sonuçları sonradan sorgulamak istemiyorsanız result backend kurmak zorunda değilsiniz. Bu örnekte doğrulama worker logundan yapılır. Başlangıç yapısı için Celery'nin Django entegrasyon belgesine bakın.

Çalışan Görev Tanımı ve İlk Test

İlk görev süresi dolmamış oturum sayısını loglar ve sözlük olarak döndürür. Bu sayı o anda çevrimiçi kişi sayısı değildir; geçerliliğini koruyan oturum kayıtlarıdır. İkinci görev Django'nun clearsessions komutunu çağırarak süresi dolan oturumları temizler. Önce deneme veritabanında uygulayın; oturum politikanızın doğru tanımlandığını kontrol edin.

# uygulama/tasks.py
import logging
from celery import shared_task
from django.contrib.sessions.models import Session
from django.core.management import call_command
from django.utils import timezone

logger = logging.getLogger(__name__)

@shared_task
def oturum_raporu():
    now = timezone.now()
    report = {
        "generated_at": now.isoformat(),
        "unexpired_sessions": Session.objects.filter(
            expire_date__gt=now
        ).count(),
    }
    logger.info("Oturum raporu: %s", report)
    return report

@shared_task
def eski_oturumlari_temizle():
    call_command("clearsessions")
    logger.info("Süresi dolan oturumların temizliği tamamlandı")
    return "completed"

Worker'ı proje kökünde ayrı terminalde başlatın. Ardından Django shell üzerinden görevi kuyruğa gönderin. Dönen kimlik mesajın kimliğidir; tamamlanmayı göstermek için worker logunda aynı kimlikle received ve succeeded satırlarını, rapor içeriğiyle birlikte arayın. Görevi doğrudan fonksiyon gibi çağırmak broker bağlantısını test etmez.

# Birinci terminal
celery -A proje worker --loglevel=info

# İkinci terminal
python manage.py shell

from uygulama.tasks import oturum_raporu
result = oturum_raporu.delay()
print(result.id)

Bu görevlerde otomatik yeniden deneme tanımlamadık. Yalnızca max_retries belirtmek tekrar denemeyi başlatmaz; uygun hata durumunda retry çağrısı veya açık autoretry_for gerekir. Geçici ağ hataları ile kalıcı veri hatalarını ayırın; her istisnayı sınırsız denemek kuyruğu doldurabilir. Celery görev belgesi yeniden deneme ve tekrar güvenliği seçeneklerini açıklar.

Admin ve ORM ile Gerçek Zamanlama Senaryoları

Beş dakikalık operasyon raporu: Oturum tablosundaki büyümeyi takip etmek için ilk görevi beş dakikalık interval ile çalıştırın. Bu görevin amacı kullanıcı etkinliğini kesin ölçmek değil, belirli bir tablonun durumunu düzenli kaydetmektir. Veritabanı büyüdüğünde sayım maliyetini ölçün ve rapor aralığını buna göre seçin.

Gece oturum temizliği: İkinci görevi her gece Türkiye saatine göre 03:00'e koyun. Oturum sayımıyla aynı anda çalıştırmak zorunda değilsiniz. Django süresi dolan oturum kayıtlarını her istekte topluca temizlemez; bakım işinin amacı artık kullanılmayan kayıtların birikmesini önlemektir. Ayrıntılar Django oturum belgesinde bulunur.

Aşağıdaki kodu manage.py shell içinde çalıştırın. Sabit isimlerle update_or_create kullanmak bu kurulum kodunun tekrar çalıştırıldığında ikinci bir periyodik kayıt açmasını engeller. Aynı işleri ayrıca CELERY_BEAT_SCHEDULE içine eklemeyin; farklı isimli kayıtlar aynı fonksiyonu iki kere tetikleyebilir.

from django_celery_beat.models import (
    CrontabSchedule, IntervalSchedule, PeriodicTask,
)

interval, _ = IntervalSchedule.objects.get_or_create(
    every=5, period=IntervalSchedule.MINUTES,
)
PeriodicTask.objects.update_or_create(
    name="bes-dakikalik-oturum-raporu",
    defaults={
        "task": "uygulama.tasks.oturum_raporu",
        "interval": interval,
        "crontab": None,
        "args": "[]",
        "kwargs": "{}",
        "enabled": True,
    },
)

night, _ = CrontabSchedule.objects.get_or_create(
    minute="0", hour="3",
    day_of_week="*", day_of_month="*", month_of_year="*",
    timezone="Europe/Istanbul",
)
PeriodicTask.objects.update_or_create(
    name="gecelik-oturum-temizligi",
    defaults={
        "task": "uygulama.tasks.eski_oturumlari_temizle",
        "crontab": night,
        "interval": None,
        "args": "[]",
        "kwargs": "{}",
        "enabled": True,
    },
)

Admin kullanıyorsanız Periodic Tasks bölümünde adı, tam görev yolunu ve yalnızca bir zamanlama türünü seçin; Enabled alanını kontrol edin. Argümanlar Python sözlüğü değil geçerli JSON olmalıdır: anahtarlar ve metinler çift tırnakla yazılır. Eklentinin modelleri ve Admin kullanımı için django-celery-beat belgesini inceleyin.

Gerçek senaryo: Berlin mağazasının raporunu yerel saate taşımak

Projenin genel saati Europe/Istanbul olsa bile Berlin'deki operasyon ekibi raporu kendi yerel saatiyle 04:15'te isteyebilir. Görevi sabit bir UTC saatine çevirmek, yaz ve kış saati geçişlerinde yerel çalışma saatini değiştirir. DatabaseScheduler kullanırken çözüm, bu takvime ait CrontabSchedule kaydında Europe/Berlin değerini açıkça saklamaktır; mevcut oturum_raporu görevi bu senaryoda veri değiştirmeyen güvenli bir örnektir.

1. Bu takvim için ayrı bir CrontabSchedule oluşturun. Başka görevlerle paylaşılan bir kaydın saat dilimini doğrudan değiştirmek, o görevlerin saatini de istemeden kaydırır.
2. PeriodicTask kaydını sabit adla oluşturun veya güncelleyin. Yalnızca crontab alanını bağlayın; interval alanının boş olduğunu ve tam görev yolunun worker kaydıyla aynı olduğunu doğrulayın.
3. Test ortamında saati birkaç dakika sonrasına ayarlayıp Beat'in Sending due task ve worker'ın succeeded satırlarını izleyin. Görevi delay ile göndermek yalnızca kuyruk yolunu sınar; CrontabSchedule takvimini test etmez.

python manage.py shell

from django_celery_beat.models import CrontabSchedule, PeriodicTask

berlin, _ = CrontabSchedule.objects.get_or_create(
    minute="15", hour="4",
    day_of_week="*", day_of_month="*", month_of_year="*",
    timezone="Europe/Berlin",
)
PeriodicTask.objects.update_or_create(
    name="berlin-gunluk-oturum-raporu",
    defaults={
        "task": "uygulama.tasks.oturum_raporu",
        "crontab": berlin,
        "interval": None,
        "args": "[]",
        "kwargs": "{}",
        "enabled": True,
    },
)

kayit = PeriodicTask.objects.get(name="berlin-gunluk-oturum-raporu")
print(kayit.crontab.timezone, kayit.enabled, kayit.task)

Saat dilimini sonradan değiştirirken Admin'i veya model nesnesini kaydeden bir işlem kullanın; böylece eklentinin değişiklik bildirimi çalışır. Toplu QuerySet.update sonrasında ise önceki bölümdeki PeriodicTasks.update_changed adımı gerekir. Üretimde last_run_at değerini otomatik sıfırlamayın: önce ek bir çalışmanın raporu tekrar üretip üretmeyeceğini değerlendirin. Bu senaryodaki asıl kontrol noktası, genel Django ayarının doğru görünmesi değil, zamanlama kaydının kendi bölgesi ile Beat'in okuduğu değerin aynı olmasıdır.

Beat'i Çalıştırma ve Üretim Süreç Yönetimi

Üretimde tek bir DatabaseScheduler süreci ile en az bir worker'ı bağımsız servisler olarak çalıştırın. Beat görevi yayımlar, worker yürütür; her iki sürecin de aynı proje ayarlarına ve broker'a erişmesi gerekir.

celery -A proje beat --loglevel=info \
  --scheduler django_celery_beat.schedulers:DatabaseScheduler

celery -A proje inspect ping
celery -A proje inspect registered
celery -A proje inspect active_queues

Beat için üçüncü terminal kullanın; worker açık kalmalıdır. Beat logundaki Sending due task satırı yayımlama adımını, worker'daki succeeded ise görevin tamamlandığını gösterir. inspect komutları çalışan worker'lardan yanıt toplar; yanıt gelmezse broker ayarını, kontrol mesajı desteğini ve servis erişimini araştırın.

Üretimde worker ve Beat'i ayrı systemd veya Supervisor servisleri olarak yönetin. Sanal ortamdaki celery çalıştırılabilir dosyasının tam yolunu, proje dizinini, uygulama kullanıcısını ve ortam ayarlarını açıkça belirtin. Web sunucusunun her worker'ıyla birlikte Beat başlatmayın. Dağıtımda eski ve yeni Beat'in aynı anda açık kaldığı kısa bir aralık bile çift mesaj üretebilir; devralma sırasını planlayın. Container ortamı için Docker zamanlama rehberini kullanabilirsiniz.

Saat Dilimi, Tekrar Güvenliği ve Değişiklikler

Interval, belirli bir aralıkla; crontab ise takvim saatine göre planlanır. Her gün 03:00 için 24 saatlik interval yerine crontab seçmek niyetinizi daha doğru ifade eder. CrontabSchedule üzerindeki timezone değerini de kontrol edin; yalnızca Django TIME_ZONE ayarını değiştirmek mevcut kayıtların geçmiş durumunu düzeltmeyebilir. Saat dilimi rehberi operasyon ekibiyle ortak saat tanımı oluşturmanıza yardımcı olur.

Toplu QuerySet.update işlemleri model save sinyallerini çalıştırmaz. Böyle bir değişiklikten sonra Beat'in değişimi görmesi için aşağıdaki bildirimi kullanın. Saat dilimi geçişinde last_run_at sıfırlaması da gerekebilir; bunu bakım sırasında, etkilenen kayıtları seçerek yapın. Sıfırlanan zamanlama beklediğinizden erken çalışabileceği için bütün görevlerin geçmişini düşünmeden silmeyin.

from django_celery_beat.models import PeriodicTask, PeriodicTasks

# Yalnızca saat dilimi geçişinde incelenmiş kayıtlar için:
PeriodicTask.objects.filter(
    name="gecelik-oturum-temizligi"
).update(last_run_at=None)
PeriodicTasks.update_changed()

update_changed çağrısı eklentinin model kaynak kodunda bulunur. Tek Beat, çalışan görevlerin birbirleriyle çakışmasını önlemez. İş aralıktan uzun sürüyorsa ortak kilit veya dönem anahtarı kullanın. Ödeme ve e-posta gibi yan etkiler için aynı iş kimliğiyle ikinci denemeyi güvenli atlayacak veritabanı kısıtları tasarlayın.

Doğrulama ve sorun giderme

Arızayı sırayla Beat, broker ve worker katmanında ayırın. Önce zamanlama kaydını ve tek Beat sürecini, sonra kuyruk ile görev kaydını, en son aynı görev kimliğine ait worker sonucunu doğrulayın; bu sıra rastgele yeniden başlatmaların kanıtları kaybetmesini önler.

Aşağıdaki Celery komutlarını proje kökünde ve sanal ortamı etkin kullanıcıyla çalıştırın. Worker ve Beat ayrı servislerdeyse aynı proje koduna, ortam değişkenlerine ve veritabanına eriştiklerinden emin olun.

Aşağıdaki örnekte aynı görev kimliği üç aşamayı bağlar. Beat'in göndermesi ve worker'ın mesajı alması tek başına başarı değildir; succeeded satırı ve uygulamanın beklenen etkisi birlikte aranmalıdır.

[2026-10-28 03:00:00,004: INFO/Beat] Scheduler: Sending due task gecelik-oturum-temizligi (uygulama.tasks.eski_oturumlari_temizle)
[2026-10-28 03:00:00,041: INFO/MainProcess] Task uygulama.tasks.eski_oturumlari_temizle[2e697c26-96ee-4c93-9486-cf17d4f9cb2a] received
[2026-10-28 03:00:00,129: INFO/ForkPoolWorker-1] Task uygulama.tasks.eski_oturumlari_temizle[2e697c26-96ee-4c93-9486-cf17d4f9cb2a] succeeded in 0.087s: 'completed'

Received satırı var ama succeeded yoksa worker logunda aynı kimlikle hata veya yeniden deneme arayın. HTTP tetiklemede 202 yanıtı da yalnızca kuyruğa kabulü gösterir; bu ayrımı izleme kayıtlarınızda koruyun.

Sık Hatalar ve Çözüm Sırası

Received unregistered task of type

Mesajdaki görev adı worker'ın kayıtlarıyla uyuşmuyordur. inspect registered çıktısını kontrol edin; uygulamanın INSTALLED_APPS içinde ve fonksiyonun tasks.py içinde olduğunu doğrulayın. Yeni kod dağıtıldıktan sonra eski worker'ı yeniden başlatın.

Connection refused veya Error 111 connecting

Broker çalışmıyor, adres yanlış veya port erişilemiyor olabilir. Redis istemcisi paketini kurmak Redis servisini başlatmaz. Web, Beat ve worker ortamlarındaki broker adreslerini karşılaştırın; container içindeki localhost varsayımını düzeltin. Redis'i herkese açık erişime açmayın.

no such table: django_celery_beat_periodictask

SQLite üzerinde bu mesaj geçişlerin eksik veya yanlış veritabanına uygulanmış olabileceğini gösterir. Beat'in kullandığı ortamda migrate çalıştırın ve bağlantı ayarını doğrulayın. PostgreSQL gibi başka motorlar eksik tabloyu farklı ifadeyle bildirir.

Beat gönderiyor fakat worker çalıştırmıyor

Görev farklı kuyruğa yönlendirilmiş olabilir. PeriodicTask üzerindeki queue alanını, uygulamanın routing ayarlarını ve active_queues çıktısını karşılaştırın. Worker kapalıysa broker mesajı kabul edebilir; Sending due task satırını başarı kanıtı saymayın.

Görev iki kez çalışıyor veya Admin değişikliği görünmüyor

İki Beat süreci, hem statik hem veritabanı kaydı veya aynı işi çağıran dış zamanlayıcı arayın. Değişiklik görünmüyorsa DatabaseScheduler seçimini ve toplu güncellemeden sonra değişim bildirimini kontrol edin. Görevi rastgele silip yeniden oluşturmak yerine önce hangi kaydın gönderdiğini loglardan bulun.

cronjob.com.tr ile HTTP Üzerinden Kuyruğa Gönderme

Beat servisi işletmek istemiyorsanız belirli bir görevi HTTPS üzerinden kuyruğa gönderebilirsiniz. Bu seçenek broker ve worker ihtiyacını kaldırmaz; yalnızca zamanlamayı dışarı taşır. Aynı görev için Beat kaydını devre dışı bırakın. Aşağıdaki endpoint yalnızca sabit rapor görevini kabul eder, dışarıdan görev adı veya Python kodu almaz.

# proje/settings.py
CRON_HTTP_TOKEN = os.environ["CRON_HTTP_TOKEN"]

# uygulama/views.py
from django.conf import settings
from django.http import JsonResponse
from django.utils.crypto import constant_time_compare
from django.views.decorators.csrf import csrf_exempt
from django.views.decorators.http import require_POST
from kombu.exceptions import OperationalError
from .tasks import oturum_raporu

@csrf_exempt
@require_POST
def cron_oturum_raporu(request):
    expected = settings.CRON_HTTP_TOKEN
    supplied = request.headers.get("X-Cron-Token", "")
    if not expected or not constant_time_compare(expected, supplied):
        return JsonResponse({"error": "forbidden"}, status=403)
    try:
        job = oturum_raporu.delay()
    except OperationalError:
        return JsonResponse({"error": "broker_unavailable"}, status=503)
    return JsonResponse(
        {"status": "queued", "task_id": job.id}, status=202
    )

# proje/urls.py; mevcut urlpatterns listesine bu yolu ekleyin
from django.urls import path
from uygulama.views import cron_oturum_raporu

urlpatterns += [
    path("internal/cron/session-report/", cron_oturum_raporu),
]

CSRF istisnası yalnızca bu makine çağrısı içindir; kimlik doğrulamasını gizli header sağlar. Genel site CSRF korumasını kapatmayın. Django CSRF belgesi istisna dekoratörünün kapsamını açıklar. Token'ı sunucu ortamında tutun, loglamayın ve üretimde HTTPS zorunlu kılın.

1. Panelde https://alanadiniz.com/internal/cron/session-report/ URL'sini, POST metodunu ve X-Cron-Token header'ını girin.
2. Hazır beş dakikalık aralığı ve işin saat dilimini seçin. Önce yanlış token ile 403, doğru token ile 202 yanıtını sınayın.
3. Panelden manuel çalıştırıp task_id değerini worker loguyla eşleştirin. 202'nin tamamlanma değil kuyruğa kabul anlamına geldiğini izleme ekranınızda ayırın.

cronjob.com.tr en kısa 60 saniyelik aralığı destekler. Hazır bir dakikalık aralıkta bekleme 55 saniye, beş dakika ve üzerindeki aralıklarda ve cron ifadeli işlerde 290 saniyedir. HTTP 200–399, bağlantı hatası yoksa başarılıdır. Özel ağ adreslerine erişilmez ve HTTPS sertifikası doğrulanır; broker adresinizi dışarı açmanız gerekmez, yalnızca HTTPS uygulamanız erişilebilir olmalıdır.

Varsayılan ardışık hata eşiği 3'tür; 1–20 arasında ayarlanabilir. Eşik aşılınca erişim sorunu, düzeldiğinde kesinti süresiyle düzeldi e-postası gönderilir. Aynı iş için bildirimler arasında en az 60 dakika vardır; çalışma kayıtları 7 gün tutulur. Worker'da sonradan oluşan hatayı bu HTTP bildirimi yakalamaz; uygulama logunu ve iş sonucunu ayrıca izleyin.

Sıkça Sorulan Sorular (SSS)

Redis kullanmak zorunda mıyım?

Hayır. Celery desteklenen başka bir broker ile de çalışabilir; RabbitMQ bir seçenektir. Redis Python istemcisi ile Redis sunucusu ayrı bileşenlerdir ve istemci kurulumu sunucuyu başlatmaz.

DatabaseScheduler iki Beat sürecini tekilleştirir mi?

Hayır. Ortak veritabanı zamanlamayı saklar; aynı zamanlama için iki Beat çalıştırmak çift mesaj üretebilir. Tek aktif Beat ve kontrollü devralma düzeni kurmanız gerekir.

Görev sonuçlarını görmek için result backend şart mı?

Sonuçları görev kimliğiyle sonradan sorgulayacaksanız uygun bir result backend yapılandırın. Yalnızca görevi çalıştırmak için zorunlu değildir; bu rehberde ilk doğrulama worker loguyla yapılır.

Admin'deki last_run_at görevin bittiğini gösterir mi?

Hayır. Bu alan zamanlayıcının son gönderim durumuyla ilgilidir; worker'ın işi başarıyla tamamladığını kanıtlamaz. Tamamlanmayı worker logundan, sonuç deposundan veya uygulamanın iş kaydından doğrulayın.

Beat kapalıyken kaçan bütün görevler telafi edilir mi?

Bütün kaçırılmış dönemlerin ayrı ayrı yürütüleceğini varsaymayın. Zorunlu dönemsel işlemler için işlenen dönemleri veritabanında saklayın ve eksik dönemleri bulan ayrı bir telafi görevi yazın.

DatabaseScheduler kaydında saat dilimi neden ayrıca ayarlanır?

CrontabSchedule kaydının timezone alanı, takvim saatinin hangi bölgeye göre yorumlanacağını belirler. Django TIME_ZONE ve CELERY_TIMEZONE ayarlarını yapılandırmış olmanız mevcut her kaydın bölgesini otomatik düzeltmez; üretim değişikliğinde kaydı ve sonraki Beat davranışını birlikte doğrulayın.

202 Accepted yanıtı Celery görevinin başarıyla bittiğini kanıtlar mı?

Hayır. 202, HTTP uç noktasının görevi kuyruğa kabul ettiğini bildirir. Tamamlanmayı task_id ile worker logundaki succeeded satırından, result backend'den veya uygulamanın kalıcı iş kaydından doğrulayın; broker veya worker hatasını ayrıca izleyin.

İlgili Rehberler