diff --git a/analytics/lib/counts.py b/analytics/lib/counts.py
index 8afc0068ba..b1a6e9f68a 100644
--- a/analytics/lib/counts.py
+++ b/analytics/lib/counts.py
@@ -288,7 +288,7 @@ def do_aggregate_to_summary_table(
 
 ## Utility functions called from outside counts.py ##
 
-# called from zerver/lib/actions.py; should not throw any errors
+# called from zerver.actions; should not throw any errors
 def do_increment_logging_stat(
     zerver_object: Union[Realm, UserProfile, Stream],
     stat: CountStat,
diff --git a/docs/contributing/code-style.md b/docs/contributing/code-style.md
index 916db3cd95..8654736b96 100644
--- a/docs/contributing/code-style.md
+++ b/docs/contributing/code-style.md
@@ -155,7 +155,7 @@ object before the first thread wrote out its change.
 
 ### Using raw saves to update important model objects
 
-In most cases, we already have a function in zerver/lib/actions.py with
+In most cases, we already have a function in `zerver.actions` with
 a name like do_activate_user that will correctly handle lookups,
 caching, and notifying running browsers via the event system about your
 change. So please check whether such a function exists before writing
diff --git a/docs/overview/directory-structure.md b/docs/overview/directory-structure.md
index 0183b3b46f..04ceb7274e 100644
--- a/docs/overview/directory-structure.md
+++ b/docs/overview/directory-structure.md
@@ -23,7 +23,7 @@ paths will be familiar to Django developers.
 
 - `zerver/lib/*.py` Most library code.
 
-- `zerver/lib/actions.py` Most code doing writes to user-facing
+- `zerver/actions/*.py` Most code doing writes to user-facing
   database tables lives here. In particular, we have a policy that
   all code calling `send_event` to trigger [pushing data to
   clients](../subsystems/events-system.md) must live here.
diff --git a/docs/production/management-commands.md b/docs/production/management-commands.md
index 6036945da2..4c5dafabb3 100644
--- a/docs/production/management-commands.md
+++ b/docs/production/management-commands.md
@@ -91,12 +91,12 @@ database, for most objects, in addition to saving the changes to the
 database, one may also need to flush caches, notify the apps and open
 browser windows, and record the change in Zulip's `RealmAuditLog`
 audit history table. For almost any data change you want to do, there
-is already a function in `zerver.lib.actions.py` with a name like
+is already a function in `zerver.actions` with a name like
 `do_change_full_name` that updates that field and notifies clients
 correctly.
 
-For convenience, Zulip automatically import `zerver/models.py` and
-`zerver/lib/actions.py` into every management shell; if you need to
+For convenience, Zulip automatically imports `zerver/models.py`
+into every management shell; if you need to
 access other functions, you'll need to import them yourself.
 
 ## Other useful manage.py commands
diff --git a/docs/subsystems/management-commands.md b/docs/subsystems/management-commands.md
index 7e42a2f209..65b6d71c4f 100644
--- a/docs/subsystems/management-commands.md
+++ b/docs/subsystems/management-commands.md
@@ -51,7 +51,7 @@ project.
   (and ideally, also used in Zulip's existing code). Look for code in
   `zerver/lib/` that already does what you need. For most actions,
   you can just call a `do_change_foo` type function from
-  `zerver/lib/actions.py` to do all the work; this is usually far
+  `zerver/actions/` to do all the work; this is usually far
   better than manipulating the database directly, since the library
   functions used by the UI are maintained to correctly live-update the
   UI if needed.
diff --git a/docs/testing/testing.md b/docs/testing/testing.md
index 6045e22883..cbc5ac471a 100644
--- a/docs/testing/testing.md
+++ b/docs/testing/testing.md
@@ -32,7 +32,7 @@ because it takes a long time. Instead, your edit/refresh cycle will
 typically involve running subsets of the tests with commands like these:
 
 ```bash
-./tools/lint zerver/lib/actions.py # Lint the file you just changed
+./tools/lint zerver/models.py # Lint the file you just changed
 ./tools/test-backend zerver.tests.test_markdown.MarkdownTest.test_inline_youtube
 ./tools/test-backend MarkdownTest # Run `test-backend --help` for more options
 ./tools/test-js-with-node util
diff --git a/docs/tutorials/writing-views.md b/docs/tutorials/writing-views.md
index 4d94827c89..0e088640db 100644
--- a/docs/tutorials/writing-views.md
+++ b/docs/tutorials/writing-views.md
@@ -242,7 +242,7 @@ change the server more than once or cause unwanted side effects.
 ### Making changes to the database
 
 If the view does any modification to the database, that change is done
-in a helper function in `zerver/lib/actions.py`. Those functions are
+in a helper function in `zerver/actions/*.py`. Those functions are
 responsible for doing a complete update to the state of the server,
 which often entails both updating the database and sending any events
 to notify clients about the state change. When possible, we prefer to
diff --git a/scripts/lib/pythonrc.py b/scripts/lib/pythonrc.py
index 45fbf56669..43d7950000 100644
--- a/scripts/lib/pythonrc.py
+++ b/scripts/lib/pythonrc.py
@@ -2,7 +2,6 @@ try:
     from django.conf import settings  # noqa: F401
 
     from analytics.models import *  # noqa: F401, F403
-    from zerver.lib.actions import *  # noqa: F401, F403
     from zerver.models import *  # noqa: F401, F403
 except Exception:
     import traceback
diff --git a/tools/linter_lib/custom_check.py b/tools/linter_lib/custom_check.py
index a489dde55a..acc69738cb 100644
--- a/tools/linter_lib/custom_check.py
+++ b/tools/linter_lib/custom_check.py
@@ -374,7 +374,7 @@ python_rules = RuleList(
         },
         {
             "pattern": "get_stream[(]",
-            "include_only": {"zerver/views/", "zerver/actions/", "zerver/lib/actions.py"},
+            "include_only": {"zerver/views/", "zerver/actions/"},
             "exclude_line": {
                 # This one in check_message is kinda terrible, since it's
                 # how most instances are written, but better to exclude something than nothing
diff --git a/tools/test-queue-worker-reload b/tools/test-queue-worker-reload
index 4ee137cd6e..589728937b 100755
--- a/tools/test-queue-worker-reload
+++ b/tools/test-queue-worker-reload
@@ -88,7 +88,7 @@ if __name__ == "__main__":
     time.sleep(1.3)
 
     print("Attempting to modify a file")
-    os.utime("zerver/lib/actions.py")
+    os.utime("zerver/models.py")
     failed = check_worker_launch(run_dev)
 
     run_dev.send_signal(signal.SIGINT)
diff --git a/zerver/lib/actions.py b/zerver/lib/actions.py
deleted file mode 100644
index 8b13789179..0000000000
--- a/zerver/lib/actions.py
+++ /dev/null
@@ -1 +0,0 @@
-
diff --git a/zerver/tornado/django_api.py b/zerver/tornado/django_api.py
index af9d6b9d05..dc3da3f362 100644
--- a/zerver/tornado/django_api.py
+++ b/zerver/tornado/django_api.py
@@ -149,7 +149,7 @@ def send_notification_http(realm: Realm, data: Mapping[str, Any]) -> None:
 # The core function for sending an event from Django to Tornado (which
 # will then push it to web and mobile clients for the target users).
 # By convention, send_event should only be called from
-# zerver/lib/actions.py, which helps make it easy to find event
+# zerver/actions/*.py, which helps make it easy to find event
 # generation code.
 #
 # Every call point should be covered by a test in `test_events.py`,