From 7f000a6df61e6795eeae4a7ccd22926e97358a46 Mon Sep 17 00:00:00 2001
From: Mirna Wong <89008547+mirnawong1@users.noreply.github.com>
Date: Fri, 15 Nov 2024 09:36:42 +0000
Subject: [PATCH] Update website/docs/docs/cloud/about-cloud-develop-defer.md

---
 website/docs/docs/cloud/about-cloud-develop-defer.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/docs/docs/cloud/about-cloud-develop-defer.md b/website/docs/docs/cloud/about-cloud-develop-defer.md
index 5f8a47fd714..0a43e201269 100644
--- a/website/docs/docs/cloud/about-cloud-develop-defer.md
+++ b/website/docs/docs/cloud/about-cloud-develop-defer.md
@@ -16,7 +16,7 @@ Both the dbt Cloud IDE and the dbt Cloud CLI enable users to natively defer to p
 When using `--defer`, dbt Cloud will follow this order of execution for resolving the `{{ ref() }}` functions.
 
 1. If a development version of a deferred relation exists, dbt preferentially uses the development database location when resolving the reference.
-2. If a development version does not exist, dbt uses the staging locations of parent relations based on metadata from the staging environment.
+2. If a development version doesn't exist, dbt uses the staging locations of parent relations based on metadata from the staging environment.
 3. If a development version AND staging version do not exist, dbt uses the production locations of parent relations based on metadata from the production environment.
 
 **Note:** Passing the `--favor-state` flag will always resolve refs using production metadata, regardless of the presence of a development relation, skipping step #1.