diff --git a/docs/src/model_creation/dsl_advanced.md b/docs/src/model_creation/dsl_advanced.md
index 3e42269b28..4edd069ba0 100644
--- a/docs/src/model_creation/dsl_advanced.md
+++ b/docs/src/model_creation/dsl_advanced.md
@@ -85,7 +85,7 @@ Generally, there are four main reasons for specifying species/parameters using t
 3. To designate metadata for species/parameters (described [here](@ref dsl_advanced_options_species_and_parameters_metadata)).
 4. To designate a species or parameters that do not occur in reactions, but are still part of the model (e.g a [parametric initial condition](@ref dsl_advanced_options_parametric_initial_conditions))
 
-!!! warn
+!!! warning
     Catalyst's DSL automatically infer species and parameters from the input. However, it only does so for *quantities that appear in reactions*. Until now this has not been relevant. However, this tutorial will demonstrate cases where species/parameters that are not part of reactions are used. These *must* be designated using either the `@species` or `@parameters` options (or the `@variables` option, which is described [later](@ref constraint_equations)).
 
 ### [Setting default values for species and parameters](@id dsl_advanced_options_default_vals)
@@ -496,7 +496,7 @@ sol = solve(oprob)
 plot(sol)
 ```
 
-!!! warn
+!!! warning
     Just like when using `@parameters` and `@species`, `@unpack` will overwrite any variables in the current scope which share name with the imported quantities.
 
 ### [Interpolating variables into the DSL](@id dsl_advanced_options_symbolics_and_DSL_interpolation)
diff --git a/docs/src/model_creation/programmatic_CRN_construction.md b/docs/src/model_creation/programmatic_CRN_construction.md
index 5232db3886..d5d12911c8 100644
--- a/docs/src/model_creation/programmatic_CRN_construction.md
+++ b/docs/src/model_creation/programmatic_CRN_construction.md
@@ -61,7 +61,7 @@ system to be the same as the name of the variable storing the system.
 Alternatively, one can use the `name = :repressilator` keyword argument to the
 `ReactionSystem` constructor.
 
-!!! warn
+!!! warning
        All `ReactionSystem`s created via the symbolic interface (i.e. by calling `ReactionSystem` with some input, rather than using `@reaction_network`) are not marked as complete. To simulate them, they must first be marked as *complete*, indicating to Catalyst and ModelingToolkit that they represent finalized models. This can be done using the `complete` function, i.e. by calling `repressilator = complete(repressilator)`. An expanded description on *completeness* can be found [here](@ref completeness_note).
 
 We can check that this is the same model as the one we defined via the DSL as
diff --git a/docs/src/model_simulation/simulation_structure_interfacing.md b/docs/src/model_simulation/simulation_structure_interfacing.md
index d8c9463234..4f44863036 100644
--- a/docs/src/model_simulation/simulation_structure_interfacing.md
+++ b/docs/src/model_simulation/simulation_structure_interfacing.md
@@ -52,7 +52,7 @@ oprob[[:S₁, :S₂]]
 ```
 Generally, when updating problems, it is often better to use the [`remake` function](@ref simulation_structure_interfacing_problems_remake) (especially when several values are updated).
 
-!!! warn
+!!! warning
     Indexing *should not* be used not modify `JumpProblem`s. Here, [remake](@ref simulation_structure_interfacing_problems_remake) should be used exclusively.
 
 A problem's time span can be accessed through the `tspan` field:
@@ -196,5 +196,5 @@ oprob[two_state_model.X1 + two_state_model.X2]
 ```
 This can be used to form symbolic expressions using model quantities when a model has been created using the DSL (as an alternative to @unpack). Alternatively, [creating an observable](@ref dsl_advanced_options_observables), and then interface using its `Symbol` representation, is also possible.
 
-!!! warn
+!!! warning
     With interfacing with a simulating structure using symbolic variables stored in a `ReactionSystem` model, ensure that the model is complete.
\ No newline at end of file
diff --git a/docs/src/steady_state_functionality/steady_state_stability_computation.md b/docs/src/steady_state_functionality/steady_state_stability_computation.md
index 08e6fa69b2..c51b55cd2a 100644
--- a/docs/src/steady_state_functionality/steady_state_stability_computation.md
+++ b/docs/src/steady_state_functionality/steady_state_stability_computation.md
@@ -1,7 +1,7 @@
 # [Steady state stability computation](@id steady_state_stability)
 After system steady states have been found using [HomotopyContinuation.jl](@ref homotopy_continuation), [NonlinearSolve.jl](@ref steady_state_solving), or other means, their stability can be computed using Catalyst's `steady_state_stability` function. Systems with conservation laws will automatically have these removed, permitting stability computation on systems with singular Jacobian.
 
-!!! warn 
+!!! warning 
     Catalyst currently computes steady state stabilities using the naive approach of checking whether a system's largest eigenvalue real part is negative. While more advanced stability computation methods exist (and would be a welcome addition to Catalyst), there is no direct plans to implement these. Furthermore, Catalyst uses a tolerance `tol = 10*sqrt(eps())` to determine whether a computed eigenvalue is far away enough from 0 to be reliably used. This threshold can be changed through the `tol` keyword argument.
 
 ## [Basic examples](@id steady_state_stability_basics)
@@ -59,5 +59,5 @@ stabs_2 = [steady_state_stability(st, sa_loop, ps_2; ss_jac) for st in steady_st
 nothing # hide
 ```
 
-!!! warn
+!!! warning
     For systems with [conservation laws](@ref homotopy_continuation_conservation_laws), `steady_state_jac` must be supplied a `u0` vector (indicating species concentrations for conservation law computation). This is required to eliminate the conserved quantities, preventing a singular Jacobian. These are supplied using the `u0` optional argument.
\ No newline at end of file