diff --git a/hc/accounts/views.py b/hc/accounts/views.py index 2bcf62eb..604664b4 100644 --- a/hc/accounts/views.py +++ b/hc/accounts/views.py @@ -83,9 +83,13 @@ def check_token(request, username, token): user = authenticate(username=username, password=token) if user is not None: if user.is_active: + # This should get rid of "welcome_code" in session + request.session.flush() + user.set_unusable_password() user.save() auth_login(request, user) + return redirect("hc-index") return render(request, "bad_link.html") diff --git a/hc/front/views.py b/hc/front/views.py index 4f4bf76f..e850f514 100644 --- a/hc/front/views.py +++ b/hc/front/views.py @@ -53,9 +53,17 @@ def pricing(request): def docs(request): + if "welcome_code" in request.session: + code = request.session["welcome_code"] + check = Check.objects.get(code=code) + else: + check = Check(code="uuid-goes-here") + ctx = { "page": "docs", - "ping_endpoint": settings.PING_ENDPOINT + "ping_endpoint": settings.PING_ENDPOINT, + "check": check, + "ping_url": check.url() } return render(request, "front/docs.html", ctx) diff --git a/static/css/bootstrap.css b/static/css/bootstrap.css index 54f6cf6d..1fc8d803 100644 --- a/static/css/bootstrap.css +++ b/static/css/bootstrap.css @@ -1258,7 +1258,7 @@ h1, } h2, .h2 { - font-size: 30px; + font-size: 24px; } h3, .h3 { diff --git a/stuff/bootstrap/variables.less b/stuff/bootstrap/variables.less index 6e624ffc..2b3d9033 100755 --- a/stuff/bootstrap/variables.less +++ b/stuff/bootstrap/variables.less @@ -53,7 +53,7 @@ @font-size-small: ceil((@font-size-base * 0.85)); // ~12px @font-size-h1: floor((@font-size-base * 2.6)); // ~36px -@font-size-h2: floor((@font-size-base * 2.15)); // ~30px +@font-size-h2: 24px; @font-size-h3: ceil((@font-size-base * 1.7)); // ~24px @font-size-h4: ceil((@font-size-base * 1.25)); // ~18px @font-size-h5: @font-size-base; diff --git a/templates/front/docs.html b/templates/front/docs.html index 20523d6c..3fc2bf66 100644 --- a/templates/front/docs.html +++ b/templates/front/docs.html @@ -4,96 +4,170 @@ {% block title %}Documentation - healthchecks.io{% endblock %} {% block content %} -
-
-

Summary

-

- Each check you create in My Checks - page has an unique "ping" URL. Whenever you access this URL, - the "Last Ping" value of corresponding check is updated. -

-

When a certain amount of time passes since last received ping, the - check is considered "late", and Health Checks sends an email alert. - It is all very simple, really.

- -

Executing a Ping

-

- At the end of your batch job, add a bit of code to request - one of your ping URLs. -

- - -

The response will have status code "200 OK" and response body will be a - short and simple string "OK".

- -

- In bash scripts, you can use wget or curl to run the requests: -

- 
-curl {{ ping_endpoint }}{uuid-goes-here}
-
- -

When Alerts Are Sent

-

- Each check has a configurable Period parameter, with the default value of one day. - For periodic tasks, this is the expected time gap between two runs. -

-

- Additionally, each check has a Grace parameter, with default value of one hour. - You can use this parameter to account for run time variance of tasks. - For example, if a backup task completes in 50 seconds one day, and - completes in 60 seconds the following day, you might not want to get - alerted because the backups are 10 seconds late. -

-

Each check can be in one of the following states:

- - - - - - - - - - - - - - - - - - -
- - - New. - A check that has been created, but has not received any pings yet. -
- - - Up. - Time since last ping has not exceeded Period. -
- - - Late. - Time since last ping has exceeded Period, - but has not yet exceeded Period + Grace. -
- - - Down. - Time since last ping has exceeded Period + Grace. - When check goes from "Late" to "Down", healthchecks.io - sends you an email alert. -
- -
-
+
+ +

Summary

+

+Each check you create in My Checks +page has an unique "ping" URL. Whenever you access this URL, +the "Last Ping" value of corresponding check is updated. +

+

When a certain amount of time passes since last received ping, the +check is considered "late", and Health Checks sends an email alert. +It is all very simple, really.

+ +

Executing a Ping

+

+ At the end of your batch job, add a bit of code to request + your ping URL. +

+ + +

The response will have status code "200 OK" and response body will be a +short and simple string "OK".

+ +

+ Here are examples of executing pings from different environments. +

+ +

Crontab

+ +

+When using cron, probably the easiest is to append a curl +or wget call after your command. The scheduled time comes, +and your command runs. After it completes, the healthchecks.io check +gets pinged. +

+ +{% include "front/snippets/crontab.html" %} + +

With this simple modification, you monitor several failure +scenarios:

+ + + +

Either way, when your task doesn't finish successfully, you will soon +know about it.

+ + +

Bash or a shell script

+ +

Both curl and wget examples accomplish the same +thing: they fire off a HTTP GET method.

+ +

+ If using curl, make sure it is installed on your target system. + Ubuntu, for example, does not have curl installed out of the box. +

+ +{% include "front/snippets/bash.html" %} + +

Python

+{% include "front/snippets/python.html" %} + +

Node

+{% include "front/snippets/node.html" %} + + +

PHP

+{% include "front/snippets/php.html" %} + +

Browser

+

+ healthchecks.io includes Access-Control-Allow-Origin:* + CORS header in its ping responses, so cross-domain AJAX requests + should work. +

+{% include "front/snippets/browser.html" %} + +

Email

+

+ As an alternative to HTTP/HTTPS requests, + you can "ping" this check by sending an + email message to {{ check.email }} +

+

+ This is useful for end-to-end testing weekly email delivery. +

+

+ An example scenario: you have a cron job which runs weekly and + sends weekly email reports to a list of e-mail 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 your emails get sent and + get delivered. +

+

+ The solution: set up another check, and add its + @hchk.io address to your list of recipient email addresses. Set its + Period to 1 week. As long as your weekly email script runs correctly, + the check will be regularly pinged and will stay up. +

+ + +

When Alerts Are Sent

+

+ Each check has a configurable Period parameter, with the default value of one day. + For periodic tasks, this is the expected time gap between two runs. +

+

+ Additionally, each check has a Grace parameter, with default value of one hour. + You can use this parameter to account for run time variance of tasks. + For example, if a backup task completes in 50 seconds one day, and + completes in 60 seconds the following day, you might not want to get + alerted because the backups are 10 seconds late. +

+

Each check can be in one of the following states:

+ + + + + + + + + + + + + + + + + + +
+ + + New. + A check that has been created, but has not received any pings yet. +
+ + + Up. + Time since last ping has not exceeded Period. +
+ + + Late. + Time since last ping has exceeded Period, + but has not yet exceeded Period + Grace. +
+ + + Down. + Time since last ping has exceeded Period + Grace. + When check goes from "Late" to "Down", healthchecks.io + sends you an email alert. +
+ +
{% endblock %} \ No newline at end of file diff --git a/templates/front/welcome.html b/templates/front/welcome.html index 47714724..28f4dd92 100644 --- a/templates/front/welcome.html +++ b/templates/front/welcome.html @@ -82,7 +82,7 @@
-

E-mail Address to Receive Alerts:

+

E-mail Address to Receive Alerts:

{% csrf_token %}