diff --git a/docs/how-tos/add-new-event-bus-concrete-implementation.rst b/docs/how-tos/add-new-event-bus-concrete-implementation.rst
index ec2400f1..e6502b4b 100644
--- a/docs/how-tos/add-new-event-bus-concrete-implementation.rst
+++ b/docs/how-tos/add-new-event-bus-concrete-implementation.rst
@@ -25,7 +25,7 @@ At a high level, the consumer should be a process that takes the signals and eve
 
 The consumer class then needs to implement ``consume_indefinitely`` loop, which will stay running and listen to events as they come in.
 
-We have included an utility function called `prepare_for_new_work_cycle <https://github.com/openedx/openedx-events/blob/26d1d3b87c8ba56f159ab20072cd231264e870f9/openedx_events/tooling.py#L332-L346>`_ in openedx-events which needs to be called before processing any signal. Currently, it reconnects the db connection if required as well as clears RequestCache and there may be later, more comprehensive changes. These steps mimic some setup/teardown that is normally performed by Django in its request/response based architecture.
+We have included a utility function called `prepare_for_new_work_cycle <https://github.com/openedx/openedx-events/blob/26d1d3b87c8ba56f159ab20072cd231264e870f9/openedx_events/tooling.py#L332-L346>`_ in openedx-events which needs to be called before processing any signal. Currently, it reconnects the db connection if required as well as clears RequestCache and there may be later, more comprehensive changes. These steps mimic some setup/teardown that is normally performed by Django in its request/response based architecture.
 
 Check out `consumer.py <https://github.com/openedx/event-bus-redis/blob/main/edx_event_bus_redis/internal/consumer.py>`_ in the event bus redis implementation.
 
diff --git a/docs/how-tos/create-a-new-event.rst b/docs/how-tos/create-a-new-event.rst
index ae541964..e3c889a3 100644
--- a/docs/how-tos/create-a-new-event.rst
+++ b/docs/how-tos/create-a-new-event.rst
@@ -186,7 +186,7 @@ The :term:`Event Definition` should be implemented in the corresponding subdomai
         }
     )
 
-- The event definition should be documented using in-line documentation with at lest ``event_type``, ``event_name``, ``event_key_field``, ``event_description``, ``event_data`` and ``event_trigger_repository``. This will help consumers understand the event and react to it. See :doc:`../reference/in-line-code-annotations-for-an-event` for more information.
+- The event definition should be documented using in-line documentation with at least ``event_type``, ``event_name``, ``event_key_field``, ``event_description``, ``event_data`` and ``event_trigger_repository``. This will help consumers understand the event and react to it. See :doc:`../reference/in-line-code-annotations-for-an-event` for more information.
 - The :term:`Event Type` should be unique and follow the naming convention for event types specified in the :doc:`../decisions/0002-events-naming-and-versioning` ADR. This is used by consumers to identify the event.
 - The ``event_name`` should be a constant that is used to identify the event in the code.
 - The ``event_key_field`` should be a field in the payload that uniquely identifies the event. This is used by consumers to identify the event.