Examples

Minimal Configuration

At minimum, you only need to specify the url you want to monitor. For example to monitor github.com:

1 probes:
2   - requests:
3       - url: https://github.com

If you didn't define the http method, it will use the GET method by default. Please note that with this configuration, you will not get any notifications when the site github.com is down since the notification configuration is not defined.

Enabling Notification

Probes are more useful with notifications enabled to alert when something is amiss. The following is an example configuration to get notification via e-mail when an incident occurs:

1 notifications:
2   - id: unique-id-smtp
3     type: smtp
4     data:
5       recipients:
6         - YOUR_EMAIL_ADDRESS_HERE
7       hostname: smtp.gmail.com
8       port: 587
9       username: YOUR_GMAIL_ACCOUNT
10       password: YOUR_GMAIL_PASSWORD_OR_APP_PASSWORD
11 probes:
12   - id: '1'
13     name: Monika Landing Page
14     description: Landing page of awesome Monika
15     interval: 10 # in seconds
16     requests:
17       - url: https://hyperjumptech.github.io/monika
18         timeout: 7000 # in milliseconds
19     alerts:
20       - assertion: response.status < 200 or response.status > 299
21         message: Target is not healthy. It has not been returning status code 2xx.
22       - assertion: response.time > 2000 # in milliseconds
23         message:
24           Target is not healthy. The response time has been greater than 2000
25           ms.

Using the above configuration, Monika will check the landing page every 10 seconds and will send a notification by email when the landing page is down 5 times in a row. For more information about available notification channels, refer to Notifications.

HTML Form Submission Example

You can also send POST requests using Monika. The following is an example of sending a POST request to simulate HTML form submission.

1 probes:
2   - id: '1'
3     name: HTML form submission
4     description: simulate html form submission
5     interval: 10 # in seconds
6     requests:
7       - method: POST
8         url: http://www.example.com/login.php
9         timeout: 7000 # in milliseconds
10         headers:
11           Content-Type: application/x-www-form-urlencoded
12         body:
13           username: someusername
14           password: somepassword

Using the configuration above, Monika will send a POST request to http://www.example.com/login.php with the defined request's body.

Multiple requests

Monika supports sending multiple requests one after another in a single probe. Below is one such configuration:

1 probes:
2   - id: '1'
3     name: Simulate form submit
4     description: simulate html form submission
5     interval: 15 # in seconds
6     requests:
7       - method: GET
8         url: https://github.com/
9         timeout: 7000 # in milliseconds
10         saveBody: false
11       - method: GET
12         url: https://github.com/hyperjumptech
13         timeout: 7000 # in milliseconds
14         saveBody: true
15     alerts:
16       - assertion: response.status > 299
17         message: Target is not healthy. It has not been returning status code 2xx.
18       - assertion: response.time > 2000 # in milliseconds
19         message:
20           Target is not healthy. The response time has been greater than 2000
21           ms.

In the configuration above, Monika will first check https://github.com/ then https://github.com/hyperjumptech. If the status code of https://github.com/ is not 2xx (e.g., 200, 201), Monika will not check https://github.com/hyperjumptech.

If there is a case where executing a GET request to https://github.com triggers an alert, the next request will not be executed.

Requests Chaining

Monika supports request chaining, which enables you to do multiple requests and the ability to use past responses from earlier requests. For example, after executing a GET request to a certain API, the next request could use the previous request(s) response into their path/assertion parameters or headers.

Here is an example on how you could get previous request(s) response data into your next request:

1 {{ responses.[0].status }} ==> Get status code from first request response
2 {{ responses.[1].body.token }} ==> Get token from second request response
3 {{ responses.[2].headers.SetCookie[0] }} ==> Get first cookie from third request response

In the example above, responses.[0] refers to the response from the first request in the probe, responses.[1] refers to the response from the second request in the probe, and so on. Please note that you can only use the response from previous requests in the same probe.

Please refer to Probe Response Anatomy in order to know which value could be used from the response body for the next request(s).

In the sections below, you can find several examples of configuration files which contain chaining requests.

Pass Response Data as Path/Query Parameters

Here is an example of using previous request's response in the path/assertion parameters:

1 probes:
2   - id: '1'
3     name: Simulate form submit
4     description: simulate html form submission
5     interval: 15 # in seconds
6     requests:
7       - method: GET
8         url: https://reqres.in/api/users
9         timeout: 7000 # in milliseconds
10       - method: GET
11         url: https://reqres.in/api/users/{{ responses.[0].body.data.[0].id }}
12         timeout: 7000 # in milliseconds
13     alerts:
14       - assertion: response.status > 299
15         message: Target is not healthy. It has not been returning status code 2xx.
16       - assertion: response.time > 2000 # in milliseconds
17         message:
18           Target is not healthy. The response time has been greater than 2000
19           ms.

In the configuration above, the first request will fetch all users from https://reqres.in/api/users. Then in the second request, Monika will fetch the details of the first user from the first request. If there are no triggered alerts, the response returned from the first request is ready to be used by the second request using values from {{ responses.[0].body }}.

Let's say the response from fetching all users in JSON format is as follows:

1 {
2   "page": 2,
3   "per_page": 6,
4   "total": 12,
5   "total_pages": 2,
6   "data": [
7     {
8         "id": 7,
9         "email": "michael.lawson@reqres.in",
10         "first_name": "Michael",
11         "last_name": "Lawson",
12         "avatar": "https://reqres.in/img/faces/7-image.jpg"
13     },
14     ...
15   ]
16 }

To use the user ID of the first user in the second request, we define the url of the second request as {{ responses.[0].body.data.[0].id }}.

Pass Response Data as Headers value

Here is an example of using previous request's response in the headers:

1 probes:
2   - id: '1'
3     name: Simulate form submit
4     description: simulate html form submission
5     interval: 15 # in seconds
6     requests:
7       - method: POST
8         url: https://reqres.in/api/login
9         timeout: 7000 # in milliseconds
10         body:
11           email: eve.holt@reqres.in
12           password: cityslicka
13       - method: POST
14         url: https://reqres.in/api/users/
15         timeout: 7000 # in milliseconds
16         body:
17           name: morpheus
18           job: leader
19         headers:
20           Authorization: Bearer {{ responses.[0].body.token }}
21     alerts:
22       - assertion: response.status > 299
23         message: Target is not healthy. It has not been returning status code 2xx.
24       - assertion: response.time > 2000 # in milliseconds
25         message:
26           Target is not healthy. The response time has been greater than 2000
27           ms.

Using the above configuration, Monika will perform a login request in the first request, then use the returned token in the Authorization header of the second request.

Pass Response Data to Request Body

Continuing with the examples from www.reqres.in above, say we would like to use the previous GET request to perform a POST /login. If the data from the initial request is something like below:

1 {
2   "data":
3     {
4       "id": 1,
5       "email": "george.bluth@reqres.in",
6       "first_name": "George",
7       "last_name": "Bluth",
8       "avatar": "https://reqres.in/img/faces/1-image.jpg"
9     },
10   ....
11 }

Then you can use the user's email in the login request body as follows:

1 probes:
2   - id: probe-01
3     name: 'body from response'
4     interval: 15 # in seconds
5 
6     requests:
7       - url: https://reqres.in/api/users/1
8         method: GET
9         timeout: 5000 # in milliseconds
10         saveBody: false
11         headers:
12           Content-Type: application/json; charset=utf-8
13 
14       - url: https://reqres.in/api/login
15         method: POST
16         timeout: 1000 # in milliseconds
17         headers:
18           Content-Type: application/json; charset=utf-8
19         body:
20           email: '{{ responses.[0].body.data.email }}'
21           password: password
22 
23         alerts:
24           - assertion: response.status != 200
25             message: Http Response status code is not 200!
26 notifications:
27   - id: unique-id-desktop
28     type: desktop

Note: Please do not forget the single quotes before and after the opening and closing double braces to explicitly indicate a string value. YAML parsers will generate warnings without it.

Errors in Request Chaining

In a request chaining mode, if one request fails, Monika does not continue with the next request in the probe. The reasoning is that, if an earlier request, say a GET /token fails, it would be pointless to continue and fetch /userdata.

If you want to continue the next request even when the first one fails, we recommend putting your requests in multiple probes, something like this:

1 probes:
2   - id: get-user
3     name: 'get-user'
4     description: login and check user app data
5     interval: 30
6     requests:
7       - url: https://example.com/token
8         body: {user: 'xxxx', password: 'yyyy'}
9         method: POST
10       - url: https://example.com/userdata
11         method: GET
12         headers:
13           Authorization: Bearer {{ responses.[0].body.accessToken }}
14 
15   - id: get-mail
16     name: 'get-mail'
17     description: fetching user emails
18     interval: 30
19     requests:
20       - url: https://example.com/token
21         body: {user: 'xxxx', password: 'yyyy'}
22         method: POST
23         timeout: 10000
24         method: POST
25       - url: https://example.com/usermail
26         method: GET
27         headers:
28           Authorization: Bearer {{ responses.[0].body.accessToken }}

In the example above, the get-email will run even if get-user has failed.