Fixing Django Signals That Fire Multiple Times on Model Save

You create a post_save signal to send a welcome email.

Everything seems correct.

Then you notice something strange:

• Two welcome emails are sent.
• Audit logs are duplicated.
• Celery tasks are queued twice.
• Notifications appear multiple times.
• API calls execute more than expected.

Your signal appears to fire multiple times even though you only called save() once.

This is one of the most common—and most confusing—issues Django developers encounter.

In reality, Django signals rarely execute "randomly." Duplicate execution is usually caused by signal registration mistakes, recursive model saves, application configuration, or development server behavior.

This guide explains why Django signals fire multiple times and how to fix the underlying causes without introducing new bugs.

What You'll Learn

After reading this guide, you'll understand:

• How Django signals work.
• Why duplicate executions occur.
• How recursive saves happen.
• Proper signal registration.
• Debugging techniques.
• Production best practices.

How Django Signals Work

Signals allow different parts of an application to react to events.

Common model signals include:

• pre_save
• post_save
• pre_delete
• post_delete
• m2m_changed

A typical example:

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=Profile)
def profile_created(sender, instance, created, **kwargs):
    if created:
        print("New profile created")

Whenever a Profile instance is saved, Django dispatches the signal.

Symptom: Signal Executes Twice

Example output:

New profile created
New profile created

Even though only one object was created.

This usually indicates one of several common issues.

Cause #1: Signal Registered Multiple Times

The most frequent cause is importing the signal module multiple times.

Incorrect setup:

# views.py
import accounts.signals

# admin.py
import accounts.signals

Every import may register another receiver.

Instead, register signals once inside your application configuration.

Example:

# apps.py

class AccountsConfig(AppConfig):
    name = "accounts"

    def ready(self):
        import accounts.signals

This ensures signals are connected in a consistent location.

Cause #2: Recursive save()

A signal that saves the same model again creates recursion.

Example:

@receiver(post_save, sender=Profile)
def update_profile(sender, instance, **kwargs):
    instance.slug = generate_slug(instance)
    instance.save()

Sequence:

save()
 ↓
post_save
 ↓
save()
 ↓
post_save
 ↓
save()

The signal repeatedly triggers itself.

Fix Recursive Saves

Instead of calling:

instance.save()

consider:

Profile.objects.filter(pk=instance.pk).update(
    slug=generate_slug(instance)
)

or update the field before the initial save whenever possible.

This avoids triggering another model save cycle.

Cause #3: Development Server Auto Reload

The Django development server uses an automatic reloader.

During development, code may appear to execute twice because two processes are involved:

• File watcher
• Application process

This behavior is normal and usually does not occur in production.

If duplicate execution only appears while running the development server, verify the behavior under your production deployment before investigating further.

Cause #4: Multiple Signal Receivers

You may unintentionally create two receivers for the same event.

Example:

@receiver(post_save, sender=Order)
def notify_sales(...):
    ...

@receiver(post_save, sender=Order)
def notify_marketing(...):
    ...

This is perfectly valid if both actions are intentional.

However, duplicate business logic spread across multiple receivers can create confusion.

Cause #5: Duplicate Receiver Registration

Using the same receiver multiple times can register duplicate handlers.

Use a dispatch UID:

post_save.connect(
    profile_created,
    sender=Profile,
    dispatch_uid="profile_created_signal"
)

dispatch_uid helps prevent the same receiver from being connected multiple times within a process.

Cause #6: Bulk Operations

Developers often expect signals to execute during:

QuerySet.update()

bulk_create()

bulk_update()

These operations intentionally bypass model save() and therefore do not trigger pre_save or post_save signals.

Understanding this behavior prevents unnecessary debugging.

Cause #7: Transactions

Signals execute immediately after save().

If a surrounding database transaction later rolls back, side effects such as emails or background jobs may already have been triggered.

Instead of performing external actions directly inside a signal, defer them until the transaction commits:

from django.db import transaction

transaction.on_commit(
    lambda: send_welcome_email(instance)
)

This ensures notifications are sent only after the database changes are successfully committed.

Debugging Signal Execution

Helpful debugging techniques include:

import logging

logger = logging.getLogger(__name__)

logger.info("Signal executed")

You can also log:

• Object ID
• Thread ID
• Process ID
• Stack traces
• Request identifiers

These details make it easier to determine whether the signal is executing multiple times or whether multiple save operations are occurring.

Organizing Signals

A clean project structure helps prevent registration issues.

Example:

accounts/
    apps.py
    models.py
    signals.py

Load signals only from:

AccountsConfig.ready()

Avoid importing signals.py throughout the project.

When Signals Are Not the Best Choice

Signals are useful for decoupling applications, but they are not always the best solution.

Business-critical workflows may be easier to understand when implemented directly inside:

• Service classes
• Model methods
• View logic
• Domain services

Keeping important business logic explicit often improves maintainability.

Real-World Example

An e-commerce application uses a post_save signal to send order confirmation emails. During testing, customers report receiving duplicate emails after placing an order. The developers initially suspect the email service, but application logs reveal that the signal is executing twice.

After investigation, they discover the signal module is imported from both apps.py and admin.py, causing the receiver to be registered multiple times. Once signal registration is centralized in AppConfig.ready() and a dispatch_uid is added, each order generates only a single confirmation email.

This demonstrates that duplicate signal execution is often caused by application configuration rather than the signal itself.

Best Practices Checklist

When using Django signals:

✅ Register signals only once

✅ Import signals in AppConfig.ready()

✅ Use dispatch_uid when appropriate

✅ Avoid recursive save() calls

✅ Use transaction.on_commit() for external actions

✅ Keep receivers lightweight

✅ Log signal execution during debugging

✅ Write automated tests for signal behavior

✅ Document signal dependencies

✅ Review whether signals are the right architectural choice

Common Mistakes to Avoid

Avoid:

❌ Importing signals.py from multiple modules

❌ Calling save() inside post_save without safeguards

❌ Sending emails before transactions commit

❌ Assuming bulk_create() triggers signals

❌ Placing complex business logic inside receivers

❌ Ignoring duplicate registrations

❌ Relying solely on development server behavior

Signals Should Remain Lightweight

Signals work best when they coordinate small, independent actions rather than orchestrating entire business workflows. Heavy processing, multiple database updates, and long-running external API calls increase complexity and make debugging more difficult. Keep receivers focused, predictable, and easy to test.

If a receiver grows substantially, it may be a sign that the logic belongs in a dedicated service layer instead.

Design for Predictable Side Effects

Applications often evolve over time, and multiple developers may add receivers for the same model events. Clear documentation, centralized registration, transaction-safe operations, and idempotent background jobs help prevent unexpected duplicate behavior as the project grows.

Treat signals as event notifications rather than primary business logic, and your codebase will remain easier to understand and maintain.

Frequently Asked Questions (FAQ)

Why is my Django signal firing twice?

Common causes include duplicate signal registration, recursive save() calls, development server auto-reload behavior, or multiple receivers listening to the same model event. Logging execution and reviewing how signals are imported usually helps identify the source.

Does bulk_create() trigger post_save?

No. Methods such as bulk_create(), bulk_update(), and QuerySet.update() bypass the model's save() method and therefore do not trigger pre_save or post_save signals.

Should I call save() inside a post_save signal?

Generally, no. Calling save() inside post_save can create recursive signal execution. If you need to update the instance, consider using QuerySet.update() where appropriate or redesign the workflow to avoid repeated saves.

Are Django signals recommended for business logic?

Signals are excellent for loosely coupled event handling, such as logging or notifications. However, complex business processes are often easier to understand, test, and maintain when implemented in service classes or explicit application logic.

Wrapping Summary

Duplicate Django signal execution is usually the result of application structure rather than a framework bug. Multiple registrations, recursive saves, development server behavior, and transaction timing are among the most common causes. By organizing signal registration through AppConfig.ready(), avoiding recursive save() calls, using dispatch_uid where appropriate, and deferring external actions until transactions commit, you can build predictable and reliable event-driven behavior.

Understanding when to use signals—and when to rely on explicit service-layer logic—will help you create Django applications that are easier to debug, maintain, and scale as your project grows.