diff --git a/templates/docs/introduction.html b/templates/docs/introduction.html
index 24d46043..7971d01b 100644
--- a/templates/docs/introduction.html
+++ b/templates/docs/introduction.html
@@ -58,12 +58,22 @@ this will be indicated by three animated dots under check's status icon.</dd>
 <p><strong>Ping URL</strong>. Each check has a unique <strong>Ping URL</strong>. Clients (cron jobs, background
 workers, batch scripts, scheduled tasks, web services) make HTTP requests to the
 ping URL to signal a start of the execution, a success, or a failure.</p>
-<p>While the "success" signals are essential, "start" and "failure" are optional.
+<p>SITE_NAME supports two ping URL formats:</p>
+<ul>
+<li><code>PING_ENDPOINT{uuid}</code><br>
+The check is identified by its UUID. Check UUIDs are assigned
+automatically by SITE_NAME, and are guaranteed to be unique.</li>
+<li><code>PING_ENDPOINT{project-ping-key}/{name-slug}</code><br>
+The check is identified by project's <strong>Ping key</strong> and check's
+<strong>slug</strong> (its name, converted to lowercase, spaces replaced with hyphens).</li>
+</ul>
+<p>You can append <code>/start</code>, <code>/fail</code> or <code>/{exitcode}</code> to the base ping URL to send
+"start" and "failure" signals. The "start" and "failure" signals are optional.
 You don't have to use them, but you can gain additional monitoring insights
-by using them. See <a href="measuring_script_run_time/">Measuring script run time</a> and
+if you do use them. See <a href="measuring_script_run_time/">Measuring script run time</a> and
 <a href="signaling_failures/">Signaling failures</a> for details.</p>
-<p>You should treat ping URLs as secrets. If you make them public, anybody can send
-telemetry signals to your checks and mess with your monitoring.</p>
+<p>You should treat check UUIDs and project Ping keys as secrets. If you make them public,
+anybody can send telemetry signals to your checks and mess with your monitoring.</p>
 <hr />
 <p><strong>Grace Time</strong> is one of the configuration parameters you can set for each check.
 It is the additional time to wait before sending an alert when a check
diff --git a/templates/docs/introduction.md b/templates/docs/introduction.md
index 78230575..2e6b7d47 100644
--- a/templates/docs/introduction.md
+++ b/templates/docs/introduction.md
@@ -68,13 +68,23 @@ Each check is always in one of the following states, depicted by a status icon:
 workers, batch scripts, scheduled tasks, web services) make HTTP requests to the
 ping URL to signal a start of the execution, a success, or a failure.
 
-While the "success" signals are essential, "start" and "failure" are optional.
+SITE_NAME supports two ping URL formats:
+
+* `PING_ENDPOINT{uuid}`<br>
+The check is identified by its UUID. Check UUIDs are assigned
+automatically by SITE_NAME, and are guaranteed to be unique.
+* `PING_ENDPOINT{project-ping-key}/{name-slug}`<br>
+The check is identified by project's **Ping key** and check's
+**slug** (its name, converted to lowercase, spaces replaced with hyphens).
+
+You can append `/start`, `/fail` or `/{exitcode}` to the base ping URL to send
+"start" and "failure" signals. The "start" and "failure" signals are optional.
 You don't have to use them, but you can gain additional monitoring insights
-by using them. See [Measuring script run time](measuring_script_run_time/) and
+if you do use them. See [Measuring script run time](measuring_script_run_time/) and
 [Signaling failures](signaling_failures/) for details.
 
-You should treat ping URLs as secrets. If you make them public, anybody can send
-telemetry signals to your checks and mess with your monitoring.
+You should treat check UUIDs and project Ping keys as secrets. If you make them public,
+anybody can send telemetry signals to your checks and mess with your monitoring.
 
 ---