Signals

Django signals are a notification system that lets certain senders tell a set of receiver functions that an action has taken place — for example, running code automatically every time a model instance is saved or deleted — so you can decouple side effects from the code that triggers them.

Learn Signals in our free Django course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Django course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

In this lesson you'll meet the built-in model signals, learn how to connect receivers with the @receiver decorator, build the classic "auto-create a profile when a user is created" pattern, and register everything correctly so it actually fires.

Every Django model fires signals at key moments in its lifecycle. The most important ones live in django.db.models.signals and fire around saving and deleting a row:

A receiver function always accepts the same keyword arguments. Django passes sender (the model class), instance (the actual object), and for save signals a created boolean. You should always end the signature with **kwargs so future arguments don't break your code.

The example below builds a tiny signal dispatcher in plain Python so you can watch post_save fire without a database. It mirrors how Django calls each connected receiver.

A receiver is just a function. To make it listen for a signal you connect it. The cleanest way is the @receiver decorator, which takes the signal and a sender to filter on:

You can also connect receivers manually with .connect() — useful when the receiver is defined elsewhere or connected conditionally:

The example below recreates that "auto-create a profile" flow with the same mini dispatcher, so you can see the created guard doing its job.

Receivers only register when their module is imported and the @receiver decorators actually run. The documented place to make that happen is the ready() method of your app's config in apps.py :

Beyond the built-ins, you can define your own custom signals for events that matter to your app. Create one with Signal() and fire it with .send() :

The runnable example wires up a custom signal end to end — define it, connect a receiver, and send it.

Fill in the blank so the receiver listens for the signal that fires right after a row is saved. The function should only print on creation.

The receiver module is never imported, so the @receiver decorators never run and nothing is connected.

✅ Fix: import your signals module from the ready() method of your app's AppConfig in apps.py .

❌ A duplicate profile is created on every update

The receiver runs on every save because the created flag isn't being checked.

✅ Fix: wrap the side effect in if created: so it only runs on the first save.

❌ RecursionError: maximum recursion depth exceeded

A post_save receiver calls .save() on the same instance, which fires post_save again, looping forever.

✅ Fix: update fields in a pre_save receiver instead, or use queryset.update() which does not re-fire the signal.

Build a small audit log. Connect receivers to both a save and a delete signal, then fire each one and watch the log fill up.

Lesson 21 complete — you can wire up signals!

You now know the built-in model signals, the sender/instance/created arguments, how to connect receivers with @receiver and .connect() , where to register them in ready() , and how to define your own custom signals.

🚀 Up next: Middleware — learn how to hook into every request and response as it passes through Django.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary