<divclass="bash highlight"><pre><span></span><code><spanclass="c1"># Send an HTTP request, 10 second timeout:</span>
<divclass="highlight"><pre><span></span><code><spanclass="c1"># Send an HTTP request, 10 second timeout:</span>
curl -m <spanclass="m">10</span> PING_URL
curl -m <spanclass="m">10</span> PING_URL
</code></pre></div>
</code></pre></div>
<h2>Use Retries</h2>
<h2>Use Retries</h2>
<p>To minimize the amount of false alerts you get from SITE_NAME, instruct your HTTP
<p>To minimize the amount of false alerts you get from SITE_NAME, instruct your HTTP
client to retry failed requests several times.</p>
client to retry failed requests several times.</p>
<p>Specifying the retry policy depends on the tool you use. curl, for example, has the
<p>Specifying the retry policy depends on the tool you use. curl, for example, has the
<code>--retry</code> parameter:</p>
<code>--retry</code> parameter:</p>
<divclass="bash highlight"><pre><span></span><code><spanclass="c1"># Retry up to 5 times, uses an increasing delay between each retry (1s, 2s, 4s, 8s, ...)</span>
<divclass="highlight"><pre><span></span><code><spanclass="c1"># Retry up to 5 times, uses an increasing delay between each retry (1s, 2s, 4s, 8s, ...)</span>
curl --retry <spanclass="m">5</span> PING_URL
curl --retry <spanclass="m">5</span> PING_URL
</code></pre></div>
</code></pre></div>
<h2>Handle Exceptions</h2>
<h2>Handle Exceptions</h2>
<p>Make sure you know how your HTTP client handles failed requests. For example,
<p>Make sure you know how your HTTP client handles failed requests. For example,
if you use an HTTP library that raises exceptions, decide if you want to
if you use an HTTP library that raises exceptions, decide if you want to
<p>A boolean that turns on/off a verification step when adding an email integration.</p>
<p>If enabled, whenever an user adds an email integration, Healthchecks emails a
verification link to the new address. The new integration becomes active only
after user clicks the verification link.</p>
<p>If you are setting up a private healthchecks instance where
you trust your users, you can opt to disable the verification step. In that case,
set <code>EMAIL_USE_VERIFICATION</code> to <code>False</code>.</p>
<h2><code>LINENOTIFY_CLIENT_ID</code></h2>
<p>Default: <code>None</code></p>
<h2><code>LINENOTIFY_CLIENT_SECRET</code></h2>
<p>Default: <code>None</code></p>
<h2><code>MASTER_BADGE_LABEL</code></h2>
<p>Default: same as <code>SITE_NAME</code></p>
<h2><code>MATRIX_ACCESS_TOKEN</code></h2>
<p>Default: <code>None</code></p>
<p>The <ahref="https://matrix.org/">Matrix</a> bot user's access token, required by the Matrix
integration.</p>
<p>To set up the Matrix integration:</p>
<ul>
<li>Register a bot user (for posting notifications) in your preferred Matrix homeserver.</li>
<li>Use the <ahref="https://www.matrix.org/docs/guides/client-server-api#login">Login API call</a>
to retrieve bot user's access token. You can run it as shown in the documentation,
using curl in command shell.</li>
<li>Set the <code>MATRIX_</code> environment variables. Example:</li>
</ul>
<divclass="highlight"><pre><span></span><code><spanclass="na">MATRIX_ACCESS_TOKEN</span><spanclass="o">=</span><spanclass="s">[a long string of characters returned by the login call]</span>
<p>Specifies how often (in seconds) the Pushover servers will send the same notification
to the user.</p>
<p>More information in <ahref="https://pushover.net/api#priority">Pushover API documentation</a>.</p>
<h2><code>PUSHOVER_SUBSCRIPTION_URL</code></h2>
<p>Default: <code>None</code></p>
<p>The Pushover Subscription URL, required by the Pushover integration.</p>
<h2><code>REGISTRATION_OPEN</code></h2>
<p>Default: <code>True</code></p>
<p>A boolean that controls whether site visitors can create new accounts.
Set it to <code>False</code> if you are setting up a private Healthchecks instance, but
it needs to be publicly accessible (so, for example, your cloud services
can send pings to it).</p>
<p>If you close new user registration, you can still selectively invite users
to your team account.</p>
<h2><code>REMOTE_USER_HEADER</code></h2>
<p>Default: <code>None</code></p>
<p>Specifies the request header to use for external authentication.</p>
<p>Healthchecks supports external authentication by means of HTTP headers set by
reverse proxies or the WSGI server. This allows you to integrate it into your
existing authentication system (e.g., LDAP or OAuth) via an authenticating proxy. When this option is enabled, <strong>Healtchecks will trust the header's value implicitly</strong>, so it is <strong>very important</strong> to ensure that attackers cannot set the value themselves (and thus impersonate any user). How to do this varies by your chosen proxy, but generally involves configuring it to strip out headers that normalize to the same name as the chosen identity header.</p>
<p>To enable this feature, set the <code>REMOTE_USER_HEADER</code> value to a header you wish to authenticate with. HTTP headers will be prefixed with <code>HTTP_</code> and have any dashes converted to underscores. Headers without that prefix can be set by the WSGI server itself only, which is more secure.</p>
<p>When <code>REMOTE_USER_HEADER</code> is set, Healthchecks will:
- assume the header contains user's email address
- look up and automatically log in the user with a matching email address
- automatically create an user account if it does not exist
- disable the default authentication methods (login link to email, password)</p>
<h2><code>RP_ID</code></h2>
<p>Default: <code>None</code></p>
<p>The <ahref="https://www.w3.org/TR/webauthn-2/#relying-party-identifier">Relying Party identifier</a>,
required by the WebAuthn second-factor authentication feature.</p>
<p>Healthchecks optionally supports two-factor authentication using the WebAuthn
standard. To enable WebAuthn support, set the <code>RP_ID</code> setting to a non-null value.
Set its value to your site's domain without scheme and without port. For example,
if your site runs on <code>https://my-hc.example.org</code>, set <code>RP_ID</code> to <code>my-hc.example.org</code>.</p>
<p>Note that WebAuthn requires HTTPS, even if running on localhost. To test WebAuthn
locally with a self-signed certificate, you can use the <code>runsslserver</code> command
from the <code>django-sslserver</code> package.</p>
<h2><code>SECRET_KEY</code></h2>
<p>Default: <code>""</code> (empty string)</p>
<p>A secret key used for cryptographic signing.</p>
<p>This is a standard Django setting, read more in
Specifies how many seconds an emergency Pushoover notification
will continue to be retried for.
More information in [Pushover API documentation](https://pushover.net/api#priority).
## `PUSHOVER_EMERGENCY_RETRY_DELAY`
Default: `300` (5 minutes)
Specifies how often (in seconds) the Pushover servers will send the same notification
to the user.
More information in [Pushover API documentation](https://pushover.net/api#priority).
## `PUSHOVER_SUBSCRIPTION_URL`
Default: `None`
The Pushover Subscription URL, required by the Pushover integration.
## `REGISTRATION_OPEN`
Default: `True`
A boolean that controls whether site visitors can create new accounts.
Set it to `False` if you are setting up a private Healthchecks instance, but
it needs to be publicly accessible (so, for example, your cloud services
can send pings to it).
If you close new user registration, you can still selectively invite users
to your team account.
## `REMOTE_USER_HEADER`
Default: `None`
Specifies the request header to use for external authentication.
Healthchecks supports external authentication by means of HTTP headers set by
reverse proxies or the WSGI server. This allows you to integrate it into your
existing authentication system (e.g., LDAP or OAuth) via an authenticating proxy. When this option is enabled, **Healtchecks will trust the header's value implicitly**, so it is **very important** to ensure that attackers cannot set the value themselves (and thus impersonate any user). How to do this varies by your chosen proxy, but generally involves configuring it to strip out headers that normalize to the same name as the chosen identity header.
To enable this feature, set the `REMOTE_USER_HEADER` value to a header you wish to authenticate with. HTTP headers will be prefixed with `HTTP_` and have any dashes converted to underscores. Headers without that prefix can be set by the WSGI server itself only, which is more secure.
When `REMOTE_USER_HEADER` is set, Healthchecks will:
- assume the header contains user's email address
- look up and automatically log in the user with a matching email address
- automatically create an user account if it does not exist
- disable the default authentication methods (login link to email, password)
## `RP_ID`
Default: `None`
The [Relying Party identifier](https://www.w3.org/TR/webauthn-2/#relying-party-identifier),
required by the WebAuthn second-factor authentication feature.
Healthchecks optionally supports two-factor authentication using the WebAuthn
standard. To enable WebAuthn support, set the `RP_ID` setting to a non-null value.
Set its value to your site's domain without scheme and without port. For example,
if your site runs on `https://my-hc.example.org`, set `RP_ID` to `my-hc.example.org`.
Note that WebAuthn requires HTTPS, even if running on localhost. To test WebAuthn
locally with a self-signed certificate, you can use the `runsslserver` command