- tag=<value>
-
-
Filters the checks, and returns only the checks that are tagged with the +
Filters the checks and returns only the checks that are tagged with the specified value.
This parameter can be repeated multiple times.
Example:
@@ -196,7 +196,7 @@ and Get a list of check's status changes API calls.GET SITE_ROOT/api/v1/checks/<uuid>
GET SITE_ROOT/api/v1/checks/<unique_key>Returns a JSON representation of a single check. Accepts either check's UUID or -the
unique_key(a field derived from UUID, and returned by API responses when +theunique_key(a field derived from UUID and returned by API responses when using the read-only API key) as an identifier.Response Codes
-
@@ -295,7 +295,7 @@ Example:
number, optional, default value: {{ default_timeout }}.
A number of seconds, the expected period of this check.
Minimum: 60 (one minute), maximum: 2592000 (30 days).
-Example for 5 minute timeout:
+Example for a 5-minute timeout:
{"kind": "simple", "timeout": 300} - grace @@ -357,8 +357,8 @@ UUIDs. You can look up integration UUIDs using the "4ec5a071-2d08-4baa-898a-eb4eb3cd6941,746a083e-f542-4554-be1a-707ce16d3acc"}
- grace @@ -575,7 +575,7 @@ field values.
- seconds=<value> diff --git a/templates/docs/api.md b/templates/docs/api.md index 07516cc0..dee6cbbb 100644 --- a/templates/docs/api.md +++ b/templates/docs/api.md @@ -22,7 +22,7 @@ Endpoint Name | Endpoint Address Your requests to SITE_NAME Management API must authenticate using an API key. All API keys are project-specific. There are no account-wide API keys. By default, a project on SITE_NAME doesn't have an API key. You can create read-write -and read-only API keys in the **Project Settings** page. +and read-only API keys on the **Project Settings** page. read-write key : Has full access to all documented API endpoints. @@ -65,7 +65,7 @@ one or more tags. ### Query String Parameters tag=<value> -: Filters the checks, and returns only the checks that are tagged with the +: Filters the checks and returns only the checks that are tagged with the specified value. This parameter can be repeated multiple times. @@ -181,7 +181,7 @@ Example: `GET SITE_ROOT/api/v1/checks/
- See if the logs can be made less verbose. For example, if you have a batch job -that outputs a line of text per item processed, perhaps it can output a short -summary with the totals instead. +that outputs a line of text per item processed, perhaps it can output a summary with +the totals instead.
- If the important content is usually at the end, submit the last 10KB instead
of the first. Here is an example that submits the last 10KB of
dmesgoutput: - Finally, if for your use case it is critical to capture the entire log output, +
- Finally, if it is critical to capture the entire log output, consider using a dedicated log aggregation service for capturing the logs.
- -m <seconds>
- Maximum time in seconds that you allow the whole operation to take.
- --retry <num> -
- If a HTTP request fails, retry up to this many times. By default, curl
+
- If an HTTP request fails, retry up to this many times. By default, curl uses an increasing delay between each retry (1s, 2s, 4s, 8s, ...). See also --retry-delay.
- -f, --fail @@ -30,10 +30,10 @@ hides error messages.
- -o /dev/null
- Redirect curl's stdout to /dev/null (error messages still go to stderr). -
- Name, tags, description
- Schedule
- Assigned notification methods
- Name: names are optional, but it is a good idea to set them. -Good naming becomes especially important as you add more checks in the +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 in notifications. +and 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 diff --git a/templates/docs/configuring_checks.md b/templates/docs/configuring_checks.md index ea0a68f5..7224470b 100644 --- a/templates/docs/configuring_checks.md +++ b/templates/docs/configuring_checks.md @@ -13,9 +13,9 @@ 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 in the +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 in notifications. +and 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 diff --git a/templates/docs/configuring_notifications.html b/templates/docs/configuring_notifications.html index cbfdf801..fcedaeb4 100644 --- a/templates/docs/configuring_notifications.html +++ b/templates/docs/configuring_notifications.html @@ -1,6 +1,6 @@Configuring Notifications
You can set up multiple ways to receive notifications when checks in your account -change state. This is useful for several reasons:
+change state. Doing so is useful for several reasons:- Redundancy in case of notification failures. Set up notifications using two different notification channels (for example, email and Slack). If one transport @@ -8,7 +8,7 @@ fails (e.g., an email message goes to spam), you still receive a notification ov other channel.
- Use different notification methods depending on urgency. For example, if a low-priority housekeeping script fails, post a message in chat. If a vital service fails, -post in chat, send an email and send SMS. +post in chat, send an email, and send SMS.
- Route notifications to the right people.
- Send a warning email to account's primary email address -
- Show a warning message in the Integrations page +
- Send a warning email to the account's primary email address +
- Show a warning message on the Integrations page
- check's current status
- the number of downtimes by month, for the last two months diff --git a/templates/docs/configuring_notifications.md b/templates/docs/configuring_notifications.md index 9545a0ca..d72ba607 100644 --- a/templates/docs/configuring_notifications.md +++ b/templates/docs/configuring_notifications.md @@ -1,7 +1,7 @@ # Configuring Notifications You can set up multiple ways to receive notifications when checks in your account -change state. This is useful for several reasons: +change state. Doing so is useful for several reasons: * **Redundancy in case of notification failures.** Set up notifications using two different notification channels (for example, email and Slack). If one transport @@ -9,7 +9,7 @@ fails (e.g., an email message goes to spam), you still receive a notification ov other channel. * **Use different notification methods depending on urgency**. For example, if a low-priority housekeeping script fails, post a message in chat. If a vital service fails, -post in chat, send an email and send SMS. +post in chat, send an email, and send SMS. * Route notifications to the right people. Each notification method ("integration") belongs to a project: @@ -35,8 +35,8 @@ The "unused" sends from one month do not carry over to the next month. When an account exceeds its monthly limit, SITE_NAME will: -* Send a warning email to account's primary email address -* Show a warning message in the **Integrations** page +* Send a warning email to the account's primary email address +* Show a warning message on the **Integrations** page ## Repeated Notifications @@ -58,11 +58,11 @@ Set them up in [Account Settings › Email Reports](../../accounts/profile/notif ## Monthly Reports SITE_NAME sends monthly email reports at the start of each month. Use them -to make sure all checks have their expected state and nothing has +to make sure all checks have their expected state, and nothing has "fallen through the cracks." A monthly report shows checks from all your projects. -For each check it lists: +For each check, it lists: * check's current status * the number of downtimes by month, for the last two months diff --git a/templates/docs/configuring_prometheus.html b/templates/docs/configuring_prometheus.html index 609c2c21..e7b8fff3 100644 --- a/templates/docs/configuring_prometheus.html +++ b/templates/docs/configuring_prometheus.html @@ -2,7 +2,7 @@
- SITE_NAME will measure and display job execution times
- SITE_NAME will detect if the job runs longer than its configured grace time @@ -101,7 +101,7 @@ OK
-
If you have not already, sign up for a free SITE_NAME account.
@@ -46,20 +46,20 @@ after the command: - The whole machine goes down (power outage, janitor stumbles on wires, VPS provider problems, etc.) -
- cron daemon is not running, or has invalid configuration -
- cron does start your task, but the task exits with non-zero exit code +
- the cron daemon is not running or has an invalid configuration +
- cron does start your task, but the task exits with a non-zero exit code
- && @@ -80,8 +80,8 @@ Transient error is a timeout or an HTTP 5xx response code.
Alternatively, if you have named your integrations in SITE_NAME dashboard, you can specify integrations by their names. For this to work, your integrations -need non-empty and unique names, and they must not contain commas. The names -must match exactly, whitespace is significant.
+need non-empty unique names, and they must not contain commas. +The names must match exactly, whitespace is significant.Example:
{"channels": "Email to Alice,SMS to Alice"}
@@ -370,9 +370,9 @@ existing checks, filtered by fields listed in unique.
If SITE_NAME does not find a matching check, it creates a new check and returns it with the HTTP status code 201.
If SITE_NAME finds a matching check, it updates the existing check and -and returns it with HTTP status code 200.
+returns it with HTTP status code 200.The accepted values for the unique field are
-name, tags, timeout and grace.
name, tags, timeout, and grace.
Example:
{"name": "Backups", unique: ["name"]}
In this example, if a check named "Backups" exists, it will be returned. @@ -456,7 +456,7 @@ parameter, SITE_NAME will leave its value unchanged.
number, optional.
A number of seconds, the expected period of this check.
Minimum: 60 (one minute), maximum: 2592000 (30 days).
-Example for 5 minute timeout:
+Example for a 5-minute timeout:
{"kind": "simple", "timeout": 300}
Pause Monitoring of a Check
POST SITE_ROOT/api/v1/checks/<uuid>/pause
Disables monitoring for a check, without removing it. The check goes into a "paused" +
Disables monitoring for a check without removing it. The check goes into a "paused" state. You can resume monitoring of the check by pinging it.
This API call has no request parameters.
Response Codes
@@ -621,7 +621,7 @@ header is sometimes required by some network proxies and web servers.Delete Check
DELETE SITE_ROOT/api/v1/checks/<uuid>
Permanently deletes the check from user's account. Returns JSON representation of the +
Permanently deletes the check from the user's account. Returns JSON representation of the check that was just deleted.
This API call has no request parameters.
Response Codes
@@ -666,7 +666,7 @@ check that was just deleted.GET SITE_ROOT/api/v1/checks/<uuid>/pings/
Returns a list of pings this check has received.
This endpoint returns pings in reverse order (most recent first), and the total -number of returned pings depends on account's billing plan: 100 for free accounts, +number of returned pings depends on the account's billing plan: 100 for free accounts, 1000 for paid accounts.
Response Codes
-
@@ -735,7 +735,7 @@ number of returned pings depends on account's billing plan: 100 for free account
GET SITE_ROOT/api/v1/checks/<uuid>/flips/
GET SITE_ROOT/api/v1/checks/<unique_key>/flips/
Returns a list of "flips" this check has experienced. A flip is a change of status -(from "down" to "up", or from "up" to "down").
+(from "down" to "up," or from "up" to "down").Query String Parameters
{"kind": "simple", "timeout": 300}
@@ -375,8 +375,8 @@ channels
Alternatively, if you have named your integrations in SITE_NAME dashboard,
you can specify integrations by their names. For this to work, your integrations
- need non-empty and unique names, and they must not contain commas. The names
- must match exactly, whitespace is significant.
+ need non-empty unique names, and they must not contain commas.
+ The names must match exactly, whitespace is significant.
Example:
@@ -392,10 +392,10 @@ unique
with the HTTP status code 201.
If SITE_NAME finds a matching check, it updates the existing check and
- and returns it with HTTP status code 200.
+ returns it with HTTP status code 200.
The accepted values for the `unique` field are
- `name`, `tags`, `timeout` and `grace`.
+ `name`, `tags`, `timeout`, and `grace`.
Example:
@@ -495,7 +495,7 @@ timeout
Minimum: 60 (one minute), maximum: 2592000 (30 days).
- Example for 5 minute timeout:
+ Example for a 5-minute timeout:
{"kind": "simple", "timeout": 300}
@@ -644,7 +644,7 @@ curl SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc \
`POST SITE_ROOT/api/v1/checks/Attaching Logs
SITE_NAME ping endpoints accept HTTP HEAD, GET and POST request methods.
-When using HTTP POST, you can include arbitrary payload in the request body. +
When using HTTP POST, you can include an arbitrary payload in the request body. If the request body looks like a UTF-8 string, SITE_NAME will log the -first 10 kilobytes (10 000 bytes) of the request body, so you can inspect it later.
+first 10 kilobytes (10 000 bytes) of the request body, so that you can inspect +it later.Logging Command Output
In this example, we run certbot renew, capture its output (both the stdout
and stderr streams), and submit the captured output to SITE_NAME:
Using Runitor
Runitor is a third party utility that runs the -supplied command, captures its output and and reports to SITE_NAME. -It also measures the execution time, and retries HTTP requests on transient errors. +supplied command, captures its output and reports to SITE_NAME. +It also measures the execution time and retries HTTP requests on transient errors. Best of all, the syntax is simple and clean:
runitor -uuid your-uuid-here -- /usr/bin/certbot renew
-
-
Shell Scripts
You can easily add SITE_NAME monitoring to a shell script. All you -have to do is make a HTTP request at an appropriate place in the script. +have to do is make an HTTP request at an appropriate place in the script. curl and wget -are two common command line HTTP clients you can use.
-# Sends a HTTP GET request with curl:
+are two common command-line HTTP clients you can use.
+# Sends an HTTP GET request with curl:
curl -m 10 --retry 5 PING_URL
# Silent version (no stdout/stderr output unless curl hits an error):
@@ -17,7 +17,7 @@ curl -fsS -m 10 --retry 5 -o /dev/
Signalling Failure from Shell Scripts
+Signaling Failure from Shell Scripts
You can append /fail or /{exit-status} to any ping URL and use the resulting URL
to actively signal a failure. The exit status should be a 0-255 integer.
-SITE_NAME will interpret exit status 0 as success, and all non-zero values as failures.
+SITE_NAME will interpret exit status 0 as success and all non-zero values as failures.
The following example runs /usr/bin/certbot renew, and uses the $? variable to
look up its exit status:
#!/bin/sh
@@ -46,9 +46,9 @@ curl -m 10 --retry 5 PING_URL/Logging Command Output
-When pinging with HTTP POST, you can put extra diagnostic information in request
+
When pinging with HTTP POST, you can put extra diagnostic information in the request
body. If the request body looks like a valid UTF-8 string, SITE_NAME
-will accept and store first 10KB of the request body.
+will accept and store the first 10KB of the request body.
In the below example, certbot's output is captured and submitted via HTTP POST:
#!/bin/sh
@@ -59,7 +59,7 @@ curl -fsS -m 10 --retry 5 --data-r
Auto-provisioning New Checks
This example uses SITE_NAME Management API to create a check "on the fly"
-(if it does not already exist) and to retrieve its ping URL.
+(if it does not already exist) and retrieve its ping URL.
Using this technique, you can write services that automatically
register with SITE_NAME the first time they run.
#!/bin/bash
diff --git a/templates/docs/bash.md b/templates/docs/bash.md
index 8cd3129a..84356d65 100644
--- a/templates/docs/bash.md
+++ b/templates/docs/bash.md
@@ -1,13 +1,13 @@
# Shell Scripts
You can easily add SITE_NAME monitoring to a shell script. All you
-have to do is make a HTTP request at an appropriate place in the script.
+have to do is make an HTTP request at an appropriate place in the script.
[curl](https://curl.haxx.se/docs/manpage.html) and
[wget](https://www.gnu.org/software/wget/manual/wget.html)
-are two common command line HTTP clients you can use.
+are two common command-line HTTP clients you can use.
```bash
-# Sends a HTTP GET request with curl:
+# Sends an HTTP GET request with curl:
curl -m 10 --retry 5 PING_URL
# Silent version (no stdout/stderr output unless curl hits an error):
@@ -21,7 +21,7 @@ Here's what each curl parameter does:
: Maximum time in seconds that you allow the whole operation to take.
**--retry <num>**
-: If a HTTP request fails, retry up to this many times. By default, curl
+: If an HTTP request fails, retry up to this many times. By default, curl
uses an increasing delay between each retry (1s, 2s, 4s, 8s, ...).
See also [--retry-delay](https://curl.haxx.se/docs/manpage.html#--retry-delay).
@@ -38,11 +38,11 @@ Here's what each curl parameter does:
**-o /dev/null**
: Redirect curl's stdout to /dev/null (error messages still go to stderr).
-## Signalling Failure from Shell Scripts
+## Signaling Failure from Shell Scripts
You can append `/fail` or `/{exit-status}` to any ping URL and use the resulting URL
to actively signal a failure. The exit status should be a 0-255 integer.
-SITE_NAME will interpret exit status 0 as success, and all non-zero values as failures.
+SITE_NAME will interpret exit status 0 as success and all non-zero values as failures.
The following example runs `/usr/bin/certbot renew`, and uses the `$?` variable to
look up its exit status:
@@ -58,9 +58,9 @@ curl -m 10 --retry 5 PING_URL/$?
## Logging Command Output
-When pinging with HTTP POST, you can put extra diagnostic information in request
+When pinging with HTTP POST, you can put extra diagnostic information in the request
body. If the request body looks like a valid UTF-8 string, SITE_NAME
-will accept and store first 10KB of the request body.
+will accept and store the first 10KB of the request body.
In the below example, certbot's output is captured and submitted via HTTP POST:
@@ -74,7 +74,7 @@ curl -fsS -m 10 --retry 5 --data-raw "$m" PING_URL
## Auto-provisioning New Checks
This example uses SITE_NAME [Management API](../api/) to create a check "on the fly"
-(if it does not already exist) and to retrieve its ping URL.
+(if it does not already exist) and retrieve its ping URL.
Using this technique, you can write services that automatically
register with SITE_NAME the first time they run.
diff --git a/templates/docs/cloning_checks.html b/templates/docs/cloning_checks.html
index fd64968a..bc08a7d8 100644
--- a/templates/docs/cloning_checks.html
+++ b/templates/docs/cloning_checks.html
@@ -2,20 +2,20 @@
You can clone individual checks from the "Check Details"
page:
-The "Create a Copy..." function creates a new check in the same project, and copies
+
The "Create a Copy..." function creates a new check in the same project and copies
over the following:
-The newly created check has a different ping URL and it starts with an empty log.
+The newly created check has a different ping URL, and it starts with an empty log.
Cloning All Checks Into a New Project
It is sometimes useful to clone an entire project. For example, when recreating
an existing deployment in a new region. The SITE_NAME web interface does
-not have a function to clone an entire project, but this can be done relatively
-easily using the Management API calls. Below is an example using Python
-and the requests library:
+not have a function to clone an entire project, but you can clone all checks in the
+project relatively easily using the Management API calls.
+Below is an example using Python and the requests library:
import requests
API_URL = "SITE_ROOT/api/v1/checks/"
diff --git a/templates/docs/cloning_checks.md b/templates/docs/cloning_checks.md
index 2ef65f34..bab0062f 100644
--- a/templates/docs/cloning_checks.md
+++ b/templates/docs/cloning_checks.md
@@ -5,22 +5,22 @@ page:
-The "Create a Copy..." function creates a new check in the same project, and copies
+The "Create a Copy..." function creates a new check in the same project and copies
over the following:
* Name, tags, description
* Schedule
* Assigned notification methods
-The newly created check has a different ping URL and it starts with an empty log.
+The newly created check has a different ping URL, and it starts with an empty log.
## Cloning All Checks Into a New Project
It is sometimes useful to clone an entire project. For example, when recreating
an existing deployment in a new region. The SITE_NAME web interface does
-not have a function to clone an entire project, but this can be done relatively
-easily using the [Management API](../api/) calls. Below is an example using Python
-and the requests library:
+not have a function to clone an entire project, but you can clone all checks in the
+project relatively easily using the [Management API](../api/) calls.
+Below is an example using Python and the [requests](https://requests.readthedocs.io/en/master/) library:
```python
import requests
diff --git a/templates/docs/configuring_checks.html b/templates/docs/configuring_checks.html
index bdca653a..19681e9e 100644
--- a/templates/docs/configuring_checks.html
+++ b/templates/docs/configuring_checks.html
@@ -9,9 +9,9 @@ either in SITE_NAME web interface or by calling Management API
Each notification method ("integration") belongs to a project:
@@ -27,8 +27,8 @@ account's billing plan. The quota automatically resets at the start of each mont
The "unused" sends from one month do not carry over to the next month.
When an account exceeds its monthly limit, SITE_NAME will:
-
Repeated Notifications
If you want to receive repeated notifications for as long as a particular check is
@@ -46,10 +46,10 @@ Set them up in Account Settings
Monthly Reports
SITE_NAME sends monthly email reports at the start of each month. Use them
-to make sure all checks have their expected state and nothing has
+to make sure all checks have their expected state, and nothing has
"fallen through the cracks."
A monthly report shows checks from all your projects.
-For each check it lists:
+For each check, it lists:
Healthchecks.io supports exporting metrics and check statuses to
Prometheus, for use with Grafana.
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 clicking "Create API Keys." You will then see the link to
the Prometheus endpoint:
Update the prometheus.yml
@@ -17,4 +17,4 @@ the Prometheus endpoint:
Notice how we split up the URL and paste in the scheme, domain, and path separately.
-Reload Prometheus and your changes should be live, coming in under the hc_ prefix.
\ No newline at end of file
+Reload Prometheus, and your changes should be live, coming in under the hc_ prefix.
\ No newline at end of file
diff --git a/templates/docs/configuring_prometheus.md b/templates/docs/configuring_prometheus.md
index 1d25f8b2..cecfa518 100644
--- a/templates/docs/configuring_prometheus.md
+++ b/templates/docs/configuring_prometheus.md
@@ -4,7 +4,7 @@ Healthchecks.io 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 clicking "Create API Keys." You will then see the link to
the Prometheus endpoint:
@@ -24,4 +24,4 @@ You can copy the Prometheus endpoint URL and add it to the Prometheus configurat
Notice how we split up the URL and paste in the scheme, domain, and path separately.
-Reload Prometheus and your changes should be live, coming in under the `hc_` prefix.
+Reload Prometheus, and your changes should be live, coming in under the `hc_` prefix.
diff --git a/templates/docs/csharp.html b/templates/docs/csharp.html
index 2ed82063..70751f36 100644
--- a/templates/docs/csharp.html
+++ b/templates/docs/csharp.html
@@ -1,5 +1,5 @@
C#
-Below is an example of making a HTTP request to SITE_NAME from C#.
+Below is an example of making an HTTP request to SITE_NAME from C#.
using (var client = new System.Net.WebClient())
{
client.DownloadString("PING_URL");
diff --git a/templates/docs/csharp.md b/templates/docs/csharp.md
index 2a18c57f..a1cf5dc0 100644
--- a/templates/docs/csharp.md
+++ b/templates/docs/csharp.md
@@ -1,6 +1,6 @@
# C\#
-Below is an example of making a HTTP request to SITE_NAME from C#.
+Below is an example of making an HTTP request to SITE_NAME from C#.
```csharp
using (var client = new System.Net.WebClient())
diff --git a/templates/docs/email.html b/templates/docs/email.html
index 1555d0f7..5224d741 100644
--- a/templates/docs/email.html
+++ b/templates/docs/email.html
@@ -1,13 +1,13 @@
Email
As an alternative to HTTP/HTTPS requests, you can "ping" checks by
-sending an emails to special email addresses.
+sending email messages to special email addresses.
Use Case: Newsletter Delivery Monitoring
-Consider a cron job which runs weekly and sends weekly newsletters
-to a list of e-mail addresses. You have already set up a check to get alerted
+
Consider a cron job that runs weekly and sends weekly newsletters
+to a list of email addresses. You have already set up a check to get alerted
when your cron job fails to run. But what you ultimately want to check is if
your emails are getting sent and delivered.
The solution: set up another check, and add its email address to your list of
recipient email addresses. Set its Period to 1 week. As long as your weekly email
script runs correctly, and there are no email delivery issues,
-SITE_NAME will regularly receive an email, and the check and will stay up.
\ No newline at end of file
+SITE_NAME will regularly receive an email, and the check will stay up.
\ No newline at end of file
diff --git a/templates/docs/email.md b/templates/docs/email.md
index 93254bd7..8aaa1cde 100644
--- a/templates/docs/email.md
+++ b/templates/docs/email.md
@@ -1,18 +1,18 @@
# Email
As an alternative to HTTP/HTTPS requests, you can "ping" checks by
-sending an emails to special email addresses.
+sending email messages to special email addresses.
## Use Case: Newsletter Delivery Monitoring
-Consider a cron job which runs weekly and sends weekly newsletters
-to a list of e-mail addresses. You have already set up a check to get alerted
+Consider a cron job that runs weekly and sends weekly newsletters
+to a list of email addresses. You have already set up a check to get alerted
when your cron job fails to run. But what you ultimately want to check is if
**your emails are getting sent and delivered**.
The solution: set up another check, and add its email address to your list of
recipient email addresses. Set its Period to 1 week. As long as your weekly email
script runs correctly, and there are no email delivery issues,
-SITE_NAME will regularly receive an email, and the check and will stay up.
+SITE_NAME will regularly receive an email, and the check will stay up.
diff --git a/templates/docs/go.html b/templates/docs/go.html
index 39da92c8..b3a56284 100644
--- a/templates/docs/go.html
+++ b/templates/docs/go.html
@@ -1,5 +1,5 @@
Go
-Below is an example of making a HTTP request to SITE_NAME from Go.
+Below is an example of making an HTTP request to SITE_NAME from Go.
package main
import "fmt"
diff --git a/templates/docs/go.md b/templates/docs/go.md
index 1c04a10d..e337bc16 100644
--- a/templates/docs/go.md
+++ b/templates/docs/go.md
@@ -1,6 +1,6 @@
# Go
-Below is an example of making a HTTP request to SITE_NAME from Go.
+Below is an example of making an HTTP request to SITE_NAME from Go.
```go
package main
diff --git a/templates/docs/http_api.html b/templates/docs/http_api.html
index d2e8c156..bac77da5 100644
--- a/templates/docs/http_api.html
+++ b/templates/docs/http_api.html
@@ -70,8 +70,8 @@ OK
-Sends a "job has started!" message to SITE_NAME. This is
-optional but enables a few extra features:
+Sends a "job has started!" message to SITE_NAME. Sending a "start" signal is
+optional, but it enables a few extra features:
Sends a success or failure signal depending on the exit status
included in the URL. The exit status is a 0-255 integer. SITE_NAME
-interprets 0 as success, and all other values as failure.
+interprets 0 as success and all other values as failure.
Example
GET /5bf66975-d4c7-4bf5-bcc8-b8d8a82ea278/1 HTTP/1.0
Host: hc-ping.com
diff --git a/templates/docs/http_api.md b/templates/docs/http_api.md
index 7beca14b..d2d4cd64 100644
--- a/templates/docs/http_api.md
+++ b/templates/docs/http_api.md
@@ -81,8 +81,8 @@ OK
HEAD|GET|POST PING_ENDPOINT{uuid}/start
```
-Sends a "job has started!" message to SITE_NAME. This is
-optional but enables a few extra features:
+Sends a "job has started!" message to SITE_NAME. Sending a "start" signal is
+optional, but it enables a few extra features:
* SITE_NAME will measure and display job execution times
* SITE_NAME will detect if the job runs longer than its configured grace time
@@ -114,7 +114,7 @@ HEAD|GET|POST PING_ENDPOINT{uuid}/{exit-status}
Sends a success or failure signal depending on the exit status
included in the URL. The exit status is a 0-255 integer. SITE_NAME
-interprets 0 as success, and all other values as failure.
+interprets 0 as success and all other values as failure.
**Example**
diff --git a/templates/docs/javascript.html b/templates/docs/javascript.html
index 03a4ae26..daf5d693 100644
--- a/templates/docs/javascript.html
+++ b/templates/docs/javascript.html
@@ -1,5 +1,5 @@
Javascript
-Below is an example of making a HTTP request to SITE_NAME from Node.js.
+Below is an example of making an HTTP request to SITE_NAME from Node.js.
var https = require('https');
https.get('PING_URL').on('error', (err) => {
console.log('Ping failed: ' + err)
diff --git a/templates/docs/javascript.md b/templates/docs/javascript.md
index d30dfedc..ed59e5ad 100644
--- a/templates/docs/javascript.md
+++ b/templates/docs/javascript.md
@@ -1,6 +1,6 @@
# Javascript
-Below is an example of making a HTTP request to SITE_NAME from Node.js.
+Below is an example of making an HTTP request to SITE_NAME from Node.js.
```js
var https = require('https');
diff --git a/templates/docs/measuring_script_run_time.html b/templates/docs/measuring_script_run_time.html
index 85eb8c7a..b8840f8a 100644
--- a/templates/docs/measuring_script_run_time.html
+++ b/templates/docs/measuring_script_run_time.html
@@ -1,11 +1,11 @@
Measuring Script Run Time
Append /start to a ping URL and use it to signal when a job starts.
- After receiving a start signal, Healthchecks.io will show the check as "Started".
- It will store the "start" events and display the job execution times. The job
- execution times are calculated as the time gaps between adjacent "start" and
+ After receiving a start signal, Healthchecks.io will show the check as "Started."
+ It will store the "start" events and display the job execution times. SITE_NAME
+ calculates the job execution times as the time gaps between adjacent "start" and
"complete" events.
-Signalling a start kicks off a separate timer: the job now must signal a
-success within its configured "Grace Time", or it will get marked as "down".
+Signaling a start kicks off a separate timer: the job now must signal a
+success within its configured "Grace Time," or it will get marked as "down."
Below is a code example in Python:
import requests
URL = "PING_URL"
diff --git a/templates/docs/measuring_script_run_time.md b/templates/docs/measuring_script_run_time.md
index b0644b18..8e446ff9 100644
--- a/templates/docs/measuring_script_run_time.md
+++ b/templates/docs/measuring_script_run_time.md
@@ -1,13 +1,13 @@
# Measuring Script Run Time
Append `/start` to a ping URL and use it to signal when a job starts.
- After receiving a start signal, Healthchecks.io will show the check as "Started".
- It will store the "start" events and display the job execution times. The job
- execution times are calculated as the time gaps between adjacent "start" and
+ After receiving a start signal, Healthchecks.io will show the check as "Started."
+ It will store the "start" events and display the job execution times. SITE_NAME
+ calculates the job execution times as the time gaps between adjacent "start" and
"complete" events.
-Signalling a start kicks off a separate timer: the job now **must** signal a
-success within its configured "Grace Time", or it will get marked as "down".
+Signaling a start kicks off a separate timer: the job now **must** signal a
+success within its configured "Grace Time," or it will get marked as "down."
Below is a code example in Python:
diff --git a/templates/docs/monitoring_cron_jobs.html b/templates/docs/monitoring_cron_jobs.html
index 36f32432..929f1b38 100644
--- a/templates/docs/monitoring_cron_jobs.html
+++ b/templates/docs/monitoring_cron_jobs.html
@@ -1,7 +1,7 @@
Monitoring Cron Jobs
SITE_NAME is perfectly suited for monitoring cron jobs. All you have to do is
-update your cron job command to send a HTTP request to SITE_NAME
-after a job completes.
+update your cron job command to send an HTTP request to SITE_NAME
+after completing the job.
Let's look at an example:
$ crontab -l
# m h dom mon dow command
@@ -11,10 +11,10 @@ after a job completes.
The above job runs /home/user/backup.sh every day at 6:08. The backup
script is presumably a headless, background process. Even if it works
-correctly currently, it can start silently failing in future, without
+correctly currently, it can start silently failing in the future without
anyone noticing.
You can set up SITE_NAME to notify you whenever the backup script does not
-run on time or does not complete successfully. Here are the steps to do that.
+run on time, or it does not complete successfully. Here are the steps to do that.
-Now, each time your cron job runs, it will send a HTTP request to the ping URL.
-Since SITE_NAME knows the schedule of your cron job, it can calculate
+
Now, each time your cron job runs, it will send an HTTP request to the ping URL.
+Since SITE_NAME knows your cron job's schedule, it can calculate
the dates and times when the job should run. As soon as your cron job doesn't
report at an expected time, SITE_NAME will send you a notification.
This monitoring technique takes care of various failure scenarios that could
potentially go unnoticed otherwise:
Curl Options
-The extra options in the above example tells curl to retry failed HTTP requests, and
-to silence output unless there is an error. Feel free to adjust the curl options to
+
The extra options in the above example tell curl to retry failed HTTP requests, and
+silence output unless there is an error. Feel free to adjust the curl options to
suit your needs.
Looking up Your Machine's Time Zone
If your cron job consistently pings SITE_NAME an hour early or an hour late,
-the likely cause is a timezone mismatch: your machine may be using a different timezone
-than what is configured on SITE_NAME.
+the likely cause is a timezone mismatch: your machine may be using a timezone
+different from what you have configured on SITE_NAME.
On modern GNU/Linux systems, you can look up the time zone using the
timedatectl status command and looking for "Time zone" in its output:
$ timedatectl status
@@ -104,6 +104,6 @@ including logs from the cron daemon.
-To see logs from e.g. the last hour, and only from the cron daemon:
+To see the logs from e.g. the last hour, and only from the cron daemon:
journalctl --since "1 hour ago" -t CRON
\ No newline at end of file
diff --git a/templates/docs/monitoring_cron_jobs.md b/templates/docs/monitoring_cron_jobs.md
index 65d797d0..a4a8467b 100644
--- a/templates/docs/monitoring_cron_jobs.md
+++ b/templates/docs/monitoring_cron_jobs.md
@@ -1,8 +1,8 @@
# Monitoring Cron Jobs
SITE_NAME is perfectly suited for monitoring cron jobs. All you have to do is
-update your cron job command to send a HTTP request to SITE_NAME
-after a job completes.
+update your cron job command to send an HTTP request to SITE_NAME
+after completing the job.
Let's look at an example:
@@ -14,11 +14,11 @@ $ crontab -l
The above job runs `/home/user/backup.sh` every day at 6:08. The backup
script is presumably a headless, background process. Even if it works
-correctly currently, it can start silently failing in future, without
+correctly currently, it can start silently failing in the future without
anyone noticing.
You can set up SITE_NAME to notify you whenever the backup script does not
-run on time or does not complete successfully. Here are the steps to do that.
+run on time, or it does not complete successfully. Here are the steps to do that.
1. If you have not already, sign up for a free SITE_NAME account.
@@ -44,8 +44,8 @@ $ crontab -e
8 6 * * * /home/user/backup.sh && curl -fsS --retry 5 -o /dev/null PING_URL
```
-Now, each time your cron job runs, it will send a HTTP request to the ping URL.
-Since SITE_NAME knows the schedule of your cron job, it can calculate
+Now, each time your cron job runs, it will send an HTTP request to the ping URL.
+Since SITE_NAME knows your cron job's schedule, it can calculate
the dates and times when the job should run. As soon as your cron job doesn't
report at an expected time, SITE_NAME will send you a notification.
@@ -53,13 +53,13 @@ This monitoring technique takes care of various failure scenarios that could
potentially go unnoticed otherwise:
* The whole machine goes down (power outage, janitor stumbles on wires, VPS provider problems, etc.)
-* cron daemon is not running, or has invalid configuration
-* cron does start your task, but the task exits with non-zero exit code
+* the cron daemon is not running or has an invalid configuration
+* cron does start your task, but the task exits with a non-zero exit code
## Curl Options
-The extra options in the above example tells curl to retry failed HTTP requests, and
-to silence output unless there is an error. Feel free to adjust the curl options to
+The extra options in the above example tell curl to retry failed HTTP requests, and
+silence output unless there is an error. Feel free to adjust the curl options to
suit your needs.
**&&**
@@ -86,8 +86,8 @@ suit your needs.
## Looking up Your Machine's Time Zone
If your cron job consistently pings SITE_NAME an hour early or an hour late,
-the likely cause is a timezone mismatch: your machine may be using a different timezone
-than what is configured on SITE_NAME.
+the likely cause is a timezone mismatch: your machine may be using a timezone
+different from what you have configured on SITE_NAME.
On modern GNU/Linux systems, you can look up the time zone using the
`timedatectl status` command and looking for "Time zone" in its output:
@@ -115,7 +115,7 @@ To see live logs:
journalctl -f
```
-To see logs from e.g. the last hour, and only from the cron daemon:
+To see the logs from e.g. the last hour, and only from the cron daemon:
```bash
journalctl --since "1 hour ago" -t CRON
diff --git a/templates/docs/php.html b/templates/docs/php.html
index 4b70bbfe..2eb87dcc 100644
--- a/templates/docs/php.html
+++ b/templates/docs/php.html
@@ -1,5 +1,5 @@
PHP
-Below is an example of making a HTTP request to SITE_NAME from PHP.
+Below is an example of making an HTTP request to SITE_NAME from PHP.
file_get_contents('PING_URL');
diff --git a/templates/docs/php.md b/templates/docs/php.md
index ed9f50b8..450bad7c 100644
--- a/templates/docs/php.md
+++ b/templates/docs/php.md
@@ -1,6 +1,6 @@
# PHP
-Below is an example of making a HTTP request to SITE_NAME from PHP.
+Below is an example of making an HTTP request to SITE_NAME from PHP.
```php
file_get_contents('PING_URL');
diff --git a/templates/docs/powershell.html b/templates/docs/powershell.html
index 5961d403..439436c0 100644
--- a/templates/docs/powershell.html
+++ b/templates/docs/powershell.html
@@ -1,16 +1,16 @@
PowerShell
You can use PowerShell
and Windows Task Scheduler to automate various tasks on a Windows system.
- From within a PowerShell script it is also easy to ping SITE_NAME.
+ From within a PowerShell script, it is also easy to ping SITE_NAME.
Here is a simple PowerShell script that pings SITE_NAME. When scheduled to
run with Task Scheduler, it will essentially just send regular "I'm alive" messages.
-You can of course extend it to do more things.
+Of course, you can extend it to do more things.
# inside a PowerShell script:
Invoke-RestMethod PING_URL
-Save the above to e.g. C:\Scripts\healthchecks.ps1.
+
Save the above to e.g., C:\Scripts\healthchecks.ps1.
Then use the following command in a Scheduled Task to run the script:
powershell.exe -ExecutionPolicy bypass -File C:\Scripts\healthchecks.ps1
diff --git a/templates/docs/powershell.md b/templates/docs/powershell.md
index c8deed06..c8d740b1 100644
--- a/templates/docs/powershell.md
+++ b/templates/docs/powershell.md
@@ -2,18 +2,18 @@
You can use [PowerShell](https://msdn.microsoft.com/en-us/powershell/mt173057.aspx)
and Windows Task Scheduler to automate various tasks on a Windows system.
- From within a PowerShell script it is also easy to ping SITE_NAME.
+ From within a PowerShell script, it is also easy to ping SITE_NAME.
Here is a simple PowerShell script that pings SITE_NAME. When scheduled to
run with Task Scheduler, it will essentially just send regular "I'm alive" messages.
-You can of course extend it to do more things.
+Of course, you can extend it to do more things.
```powershell
# inside a PowerShell script:
Invoke-RestMethod PING_URL
```
-Save the above to e.g. `C:\Scripts\healthchecks.ps1`.
+Save the above to e.g., `C:\Scripts\healthchecks.ps1`.
Then use the following command in a Scheduled Task to run the script:
```bat
diff --git a/templates/docs/projects_teams.html b/templates/docs/projects_teams.html
index 3965413b..9d820152 100644
--- a/templates/docs/projects_teams.html
+++ b/templates/docs/projects_teams.html
@@ -5,7 +5,7 @@ your checks between them as your usage grows.
Checks and integrations are project-scoped: each check and each configured
integration always belongs to a particular project. Checks can be transferred
-from one project to another, preserving check's ping address:
+between projects. The transfer operation preserves check's ping address:
Team Access
You can grant your colleagues access to a project by inviting them into
@@ -47,17 +47,17 @@ limit depends on the account's billing plan. When you reach the Check Limit
you will not be able to create new checks.
All projects owned by your account shares your account's Check Limit.
For example, consider a Business account with two projects,
-"Project A" and "Project B". If A has 70 checks, then B cannot have more than
-30 checks, in order to not exceed the Business account's total limit of 100.
+"Project A" and "Project B." If A has 70 checks, then B cannot have more than
+30 checks in order to not exceed the Business account's total limit of 100.
However, only checks from your own projects count towards your account's
quota. If you get invited to somebody else's project, that does not change
the number of checks you can create in your projects.
Projects and Team Size Limits
-Team Size is the number of unique users you can invite in your projects.
+
Team Size is the number of unique users you can invite to your projects.
Same as with Check Limit, all projects share your account's Team Size limit.
However, if you invite the same user (using the same email address) into multiple
projects, it only takes up a single seat.
Projects and Monthly Reports
SITE_NAME sends monthly email reports at the start of each month. The monthly reports
list a summary of checks from all your projects. It contains status summaries for
-both the projects you own, and the projects you are a member of.
\ No newline at end of file
+both the projects you own and the projects you are a member of.
\ No newline at end of file
diff --git a/templates/docs/projects_teams.md b/templates/docs/projects_teams.md
index df13eae2..5a2df0e5 100644
--- a/templates/docs/projects_teams.md
+++ b/templates/docs/projects_teams.md
@@ -8,7 +8,7 @@ your checks between them as your usage grows.
Checks and integrations are project-scoped: each check and each configured
integration always belongs to a particular project. Checks can be transferred
-from one project to another, preserving check's ping address:
+between projects. The transfer operation preserves check's ping address:
@@ -61,8 +61,8 @@ you will not be able to create new checks.
All projects owned by your account shares your account's Check Limit.
For example, consider a Business account with two projects,
-"Project A" and "Project B". If A has 70 checks, then B cannot have more than
-30 checks, in order to not exceed the Business account's total limit of 100.
+"Project A" and "Project B." If A has 70 checks, then B cannot have more than
+30 checks in order to not exceed the Business account's total limit of 100.
However, only checks from your own projects count towards your account's
quota. If you get invited to somebody else's project, that does not change
@@ -70,7 +70,7 @@ the number of checks you can create in your projects.
## Projects and Team Size Limits
-**Team Size** is the number of *unique* users you can invite in your projects.
+**Team Size** is the number of *unique* users you can invite to your projects.
Same as with Check Limit, all projects share your account's Team Size limit.
However, if you invite the same user (using the same email address) into multiple
projects, it only takes up a single seat.
@@ -79,4 +79,4 @@ projects, it only takes up a single seat.
SITE_NAME sends monthly email reports at the start of each month. The monthly reports
list a summary of checks from **all your projects**. It contains status summaries for
-both the projects you own, and the projects you are a member of.
+both the projects you own and the projects you are a member of.
diff --git a/templates/docs/python.html b/templates/docs/python.html
index 4056685f..cd8a5cf6 100644
--- a/templates/docs/python.html
+++ b/templates/docs/python.html
@@ -1,5 +1,6 @@
Python
-If you are already using the requests library, it is convenient to also use it here:
+If you are already using the requests
+library, it is convenient to also use it here:
import requests
try:
@@ -10,7 +11,8 @@
-Otherwise, you can use the urllib module from Python 3 standard library:
+Otherwise, you can use the urllib.request
+module from Python 3 standard library:
import socket
import urllib.request
diff --git a/templates/docs/python.md b/templates/docs/python.md
index 2e643870..2950894d 100644
--- a/templates/docs/python.md
+++ b/templates/docs/python.md
@@ -1,6 +1,7 @@
# Python
-If you are already using the requests library, it is convenient to also use it here:
+If you are already using the [requests](https://requests.readthedocs.io/en/master/)
+library, it is convenient to also use it here:
```python
import requests
@@ -12,7 +13,8 @@ except requests.RequestException as e:
print("Ping failed: %s" % e)
```
-Otherwise, you can use the urllib module from Python 3 standard library:
+Otherwise, you can use the [urllib.request](https://docs.python.org/3/library/urllib.request.html)
+module from Python 3 standard library:
```python
import socket
diff --git a/templates/docs/reliability_tips.html b/templates/docs/reliability_tips.html
index efa42cd3..f27b5b9b 100644
--- a/templates/docs/reliability_tips.html
+++ b/templates/docs/reliability_tips.html
@@ -1,17 +1,18 @@
Pinging Reliability Tips
-Sending monitoring signals over public internet is inherently unreliable.
+
Sending monitoring signals over the public internet is inherently unreliable.
HTTP requests can sometimes take excessively long or fail completely
for a variety of reasons. Here are some general tips to make your monitoring
code more robust.
Specify HTTP Request Timeout
Put a time limit on how long each ping is allowed to take. This is especially
important when sending a "start" signal at the start of a job: you don't want
-a stuck ping prevent the actual job from running. Another case is a continuously
-running worker process which pings SITE_NAME after each completed item. A stuck
-request would block the whole process, so it is important to guard against.
+a stuck ping to prevent the actual job from running. Another case is a continuously
+running worker process that pings SITE_NAME after each completed item. A stuck
+request could block the whole process. An explicit per-request time limit mitigates
+this problem.
Specifying the timeout depends on the tool you use. curl, for example, has the
--max-time (shorthand: -m) parameter:
-# Send a HTTP, 10 second timeout:
+# Send an HTTP request, 10 second timeout:
curl -m 10 PING_URL
@@ -28,5 +29,5 @@ curl --retry 5 PING_URL
Handle Exceptions
Make sure you know how your HTTP client handles failed requests. For example,
-if you use a HTTP library which raises exceptions, decide if you want to
-catch the exceptions, or let them bubble up.
\ No newline at end of file
+if you use an HTTP library that raises exceptions, decide if you want to
+catch the exceptions or let them bubble up.
\ No newline at end of file
diff --git a/templates/docs/reliability_tips.md b/templates/docs/reliability_tips.md
index e6de83c5..4bc88507 100644
--- a/templates/docs/reliability_tips.md
+++ b/templates/docs/reliability_tips.md
@@ -1,6 +1,6 @@
# Pinging Reliability Tips
-Sending monitoring signals over public internet is inherently unreliable.
+Sending monitoring signals over the public internet is inherently unreliable.
HTTP requests can sometimes take excessively long or fail completely
for a variety of reasons. Here are some general tips to make your monitoring
code more robust.
@@ -9,15 +9,16 @@ code more robust.
Put a time limit on how long each ping is allowed to take. This is especially
important when sending a "start" signal at the start of a job: you don't want
-a stuck ping prevent the actual job from running. Another case is a continuously
-running worker process which pings SITE_NAME after each completed item. A stuck
-request would block the whole process, so it is important to guard against.
+a stuck ping to prevent the actual job from running. Another case is a continuously
+running worker process that pings SITE_NAME after each completed item. A stuck
+request could block the whole process. An explicit per-request time limit mitigates
+this problem.
Specifying the timeout depends on the tool you use. curl, for example, has the
`--max-time` (shorthand: `-m`) parameter:
```bash
-# Send a HTTP, 10 second timeout:
+# Send an HTTP request, 10 second timeout:
curl -m 10 PING_URL
```
@@ -37,5 +38,5 @@ curl --retry 5 PING_URL
## Handle Exceptions
Make sure you know how your HTTP client handles failed requests. For example,
-if you use a HTTP library which raises exceptions, decide if you want to
-catch the exceptions, or let them bubble up.
+if you use an HTTP library that raises exceptions, decide if you want to
+catch the exceptions or let them bubble up.
diff --git a/templates/docs/ruby.html b/templates/docs/ruby.html
index ce9acdf6..765420aa 100644
--- a/templates/docs/ruby.html
+++ b/templates/docs/ruby.html
@@ -1,5 +1,5 @@
Ruby
-Below is an example of making a HTTP request to SITE_NAME from Ruby.
+Below is an example of making an HTTP request to SITE_NAME from Ruby.
require 'net/http'
require 'uri'
diff --git a/templates/docs/ruby.md b/templates/docs/ruby.md
index 0b3e33f3..c1eb0068 100644
--- a/templates/docs/ruby.md
+++ b/templates/docs/ruby.md
@@ -1,6 +1,6 @@
# Ruby
-Below is an example of making a HTTP request to SITE_NAME from Ruby.
+Below is an example of making an HTTP request to SITE_NAME from Ruby.
```ruby
require 'net/http'
diff --git a/templates/docs/signalling_failures.html b/templates/docs/signalling_failures.html
index ba7b065b..5913fb63 100644
--- a/templates/docs/signalling_failures.html
+++ b/templates/docs/signalling_failures.html
@@ -1,8 +1,8 @@
-Signalling failures
+Signaling failures
You can actively signal a failure to SITE_NAME by slightly changing the
ping URL: append either /fail or /{exit-status} to your normal ping URL.
The exit status should be a 0-255 integer. SITE_NAME will interpret
-exit status 0 as success, and all non-zero values as failures.
+exit status 0 as success and all non-zero values as failures.
Examples:
# Reports failure by appending the /fail suffix:
curl --retry 3 PING_URL/fail
@@ -12,7 +12,7 @@ curl --retry 3 PING_URL/1
-By actively signalling failures to SITE_NAME, you can minimize the delay from your
+
By actively signaling failures to SITE_NAME, you can minimize the delay from your
monitored service encountering a problem to you getting notified about it.
Shell Scripts
The below shell script appends $? (a special variable which contains the
diff --git a/templates/docs/signalling_failures.md b/templates/docs/signalling_failures.md
index 50376591..83421213 100644
--- a/templates/docs/signalling_failures.md
+++ b/templates/docs/signalling_failures.md
@@ -1,9 +1,9 @@
-# Signalling failures
+# Signaling failures
You can actively signal a failure to SITE_NAME by slightly changing the
ping URL: append either `/fail` or `/{exit-status}` to your normal ping URL.
The exit status should be a 0-255 integer. SITE_NAME will interpret
-exit status 0 as success, and all non-zero values as failures.
+exit status 0 as success and all non-zero values as failures.
Examples:
@@ -16,7 +16,7 @@ curl --retry 3 PING_URL/fail
curl --retry 3 PING_URL/1
```
-By actively signalling failures to SITE_NAME, you can minimize the delay from your
+By actively signaling failures to SITE_NAME, you can minimize the delay from your
monitored service encountering a problem to you getting notified about it.
## Shell Scripts
diff --git a/templates/front/channels.html b/templates/front/channels.html
index c58a473d..c4ba7d06 100644
--- a/templates/front/channels.html
+++ b/templates/front/channels.html
@@ -204,7 +204,7 @@
class="icon" alt="Webhook icon" />
Webhook
- Receive a HTTP callback when a check goes down.
+ Receive an HTTP callback when a check goes down.
Add Integration
diff --git a/templates/front/docs_cron.html b/templates/front/docs_cron.html
index 843d66b9..7b87d917 100644
--- a/templates/front/docs_cron.html
+++ b/templates/front/docs_cron.html
@@ -37,7 +37,7 @@
A cron expression has five fields, separated by spaces.
- Asterisk is a wild card character and means "any value".
+ Asterisk is a wild card character and means "any value."
"Run every minute"
@@ -98,7 +98,7 @@
Use numeric values instead of asterisks to match specific
- minutes, hours, days and months.
+ minutes, hours, days, and months.
"Run at 6PM on Fridays"
@@ -160,7 +160,7 @@
Use {v1},{v2},...,{vn} to list multiple values.
- "Run at 9AM, 12PM and 6PM every day"
+ "Run at 9AM, 12PM, and 6PM every day"
@@ -245,7 +245,7 @@
- Run on Monday to Friday
+ Run from Monday to Friday
@@ -336,7 +336,7 @@
Combine numeric values and ranges in lists
- In the comma-separated lists you can combine not only
+
In the comma-separated lists, you can combine not only
numeric values but also ranges.
"Run every round hour outside office hours"
@@ -459,13 +459,13 @@
- Cron daemon uses server's local time.
+ The cron daemon uses the server's local time.
If your server's timezone is other than UTC, make sure
to set a matching timezone for your check
on {{ site_name }} as well.
- On Ubuntu systems you can check the server's timezone
+
On Ubuntu systems, you can check the server's timezone
with:
cat /etc/timezone