Fix grammar and inaccuracies in docs

templates/docs/configuring_checks.html

@@ -11,7 +11,7 @@ either in SITE_NAME web interface or via <a href="../api/">Management API</a>.</
 <li><strong>Name</strong>: names are optional, but it is a good idea to set them.
 Good naming becomes especially important as you add more checks to the
 account. SITE_NAME will display check names in the web interface, in email reports,
-and notifications.</li>
+and in notifications.</li>
 <li><strong>Tags</strong>: a space-separated list of optional labels. Use tags to organize and group
 checks within a project. You can tag checks by the environment
 (<code>prod</code>, <code>staging</code>, <code>dev</code>, etc.) or by role (<code>www</code>, <code>db</code>, <code>worker</code>, etc.) or using
@@ -67,7 +67,7 @@ SITE_NAME will treat it as an explicit failure signal.
 For example, this is useful if your backup software sends an email after each backup
 run with a different subject line depending on success or failure.</li>
 <li><strong>Filter by keywords in the message body</strong>. Same as the previous option, but
-looks for the keywords in email message body. Supports both plain text and HTML
+looks for the keywords in the email message body. Supports both plain text and HTML
 email messages.</li>
 <li><strong>Pinging a Paused Check</strong>. Normally, when you ping a paused check, it leaves the
 paused state and goes into the "up" state (or the "down" state

templates/docs/configuring_checks.md

@@ -15,7 +15,7 @@ Describe each check using an optional name, tags, and description fields.
 * **Name**: names are optional, but it is a good idea to set them.
 Good naming becomes especially important as you add more checks to the
 account. SITE_NAME will display check names in the web interface, in email reports,
-and notifications.
+and in notifications.
 * **Tags**: a space-separated list of optional labels. Use tags to organize and group
 checks within a project. You can tag checks by the environment
 (`prod`, `staging`, `dev`, etc.) or by role (`www`, `db`, `worker`, etc.) or using
@@ -80,7 +80,7 @@ SITE_NAME will treat it as an explicit failure signal.
 For example, this is useful if your backup software sends an email after each backup
 run with a different subject line depending on success or failure.
 * **Filter by keywords in the message body**. Same as the previous option, but
-looks for the keywords in email message body. Supports both plain text and HTML
+looks for the keywords in the email message body. Supports both plain text and HTML
 email messages.
 * **Pinging a Paused Check**. Normally, when you ping a paused check, it leaves the
 paused state and goes into the "up" state (or the "down" state

templates/docs/configuring_prometheus.html

@@ -2,7 +2,7 @@
 <p>SITE_NAME supports exporting metrics and check statuses to
 <a href="https://prometheus.io/">Prometheus</a>, for use with <a href="https://grafana.com/">Grafana</a>.</p>
 <p>You can generate the metrics export endpoint by going to your project settings
-and clicking "Create API Keys." You will then see the link to
+and <strong>creating a read-only API key</strong>. You will then see the link to
 the Prometheus endpoint:</p>
 <p><img alt="Project's API Keys" src="IMG_URL/prometheus_endpoint.png" /></p>
 <h2>Update the prometheus.yml</h2>

templates/docs/configuring_prometheus.md

@@ -4,7 +4,7 @@ SITE_NAME supports exporting metrics and check statuses to
 [Prometheus](https://prometheus.io/), for use with [Grafana](https://grafana.com/).
 
 You can generate the metrics export endpoint by going to your project settings
-and clicking "Create API Keys." You will then see the link to
+and **creating a read-only API key**. You will then see the link to
 the Prometheus endpoint:
 
 ![Project's API Keys](IMG_URL/prometheus_endpoint.png)

templates/docs/email.html

@@ -4,8 +4,8 @@ sending email messages to special email addresses.</p>
 <p><img alt="Email address for pinging via email" src="IMG_URL/emails.png" /></p>
 <p>By default, SITE_NAME will consider any email received at the displayed address as
 a "success" signal. You can also configure SITE_NAME to look for specific
-keywords in message's subject line to decide if the message is "success"
-or a "failure" signal. You can set up the keywords in the
+keywords in the subject line or  the message body to decide if the message
+is "success" or a "failure" signal. You can set up the keywords in the
 <strong>Filtering Rules</strong> dialog:</p>
 <p><img alt="Setting filtering rules" src="IMG_URL/filtering_rules.png" /></p>
 <h2>Use Case: Newsletter Delivery Monitoring</h2>

templates/docs/email.md

@@ -7,8 +7,8 @@ sending email messages to special email addresses.
 
 By default, SITE_NAME will consider any email received at the displayed address as
 a "success" signal. You can also configure SITE_NAME to look for specific
-keywords in message's subject line to decide if the message is "success"
-or a "failure" signal. You can set up the keywords in the
+keywords in the subject line or  the message body to decide if the message
+is "success" or a "failure" signal. You can set up the keywords in the
 **Filtering Rules** dialog:
 
 ![Setting filtering rules](IMG_URL/filtering_rules.png)

templates/docs/measuring_script_run_time.html

@@ -35,9 +35,9 @@ has failed. It will mark the job as "down" and send out alerts.</p>
 
 <h2>Viewing Measured Run Times</h2>
 <p>When SITE_NAME receives a "start" signal followed by a regular ping or a "fail"
-signal, and the two events are less than 24 hours apart,
+signal, and the two events are less than 72 hours apart,
 you will see the time delta displayed in the list of checks. If the two events are
-more than 24 hours apart, they are assumed to be unrelated, and the time delta is
+more than 72 hours apart, they are assumed to be unrelated, and the time delta is
 not displayed.</p>
 <p><img alt="List of checks with durations" src="IMG_URL/checks_durations.png" /></p>
 <p>You can also see durations of the previous runs when viewing an individual check:</p>

templates/docs/measuring_script_run_time.md

@@ -44,9 +44,9 @@ requests.get(URL)
 ## Viewing Measured Run Times
 
 When SITE_NAME receives a "start" signal followed by a regular ping or a "fail"
-signal, and the two events are less than 24 hours apart,
+signal, and the two events are less than 72 hours apart,
 you will see the time delta displayed in the list of checks. If the two events are
-more than 24 hours apart, they are assumed to be unrelated, and the time delta is
+more than 72 hours apart, they are assumed to be unrelated, and the time delta is
 not displayed.
 
 ![List of checks with durations](IMG_URL/checks_durations.png)