HTTP(S) Check

HTTP(S) check is a monitoring method that verifies the availability and performance of a web application by checking the response time of HTTP requests. Xitoring uses HTTP(S) checks to monitor web applications by sending HTTP requests to the application and measuring the response time.

During an HTTP(S) check, Xitoring verifies the HTTP status code, response time, and content of the web page to ensure the web application is functioning correctly. If there is an issue with the web application, Xitoring sends an incident to the designated Notification Roles with details about the issue, including the severity level and affected server.

HTTP(S) checks are a critical monitoring method used to detect issues with web applications, such as slow response times, server errors, and content errors. By monitoring HTTP(S) checks, Xitoring can detect and alert IT teams in real-time if there is an issue with a web application's availability or performance, allowing them to take immediate action to resolve the issue.

Create an HTTP(S) Check

In Xitoring it is possible to create a basic HTTP(S) Check to simply send a request to an endpoint and determine if that endpoint is accessible or not. But Also users can create very complex HTTP(S) Checks that also can act as API monitoring Checks. The options and configurations are available to create the HTTP(S) that suits users' needs.

Check Options

Type

From the list of available check types HTTP(S) will be selected.

Related Server

As in Xitoring, there are Server checks and independent checks, you can Create a check and assign it to a Server so it will count as one of the checks of a specific server. this option also can be changed or edited later.

So the list will contain a list of registered servers that the user can assign the check to them.

TIP

At every step of creating the HTTP(S) Check user can see the address that Xitoring will use to monitor in the Final Hostname section which will be generated in real-time when the check is being created.

Hostname

The hostname is the address of the HTTP(S) check, it can be an IPv4 or IPv6 address or a domain name, you can see examples of each of them in the following box:

IPv4
107.45.66.2

IPv6
fe80::a510:68bd:7405:1869

Domain
xitoring.com

URL

This section enables users to create a check for a certain API or Route on their Application or website, for example, Xitoring can monitor the /login of your web application or website. users just need to make sure that put the / at the start of the URL and check the final result with the Final Hostname section.

Check Label

Users can choose a name for the check that is being created using this field, Check label can contain characters, space, and numbers. Special characters are not allowed in the check label section.

Port

Some web applications and web services are being served on custom ports other than 80 or 443, So Xitoring implemented this option to make it possible to create an HTTP(S) Check for any port number.

TIP

Ports 80 and 433 which are the standard ports for HTTP(S) are not shown in the Final Hostname section.

Method

Xitoring's HTTP(S) checks allow users to select the HTTP method for their checks. The supported methods include GET, POST, PUT, and PATCH.

GET is used to retrieve information from a server, while POST is used to submit data to a server. PUT and PATCH are used to update or modify existing resources on the server.

By offering support for different HTTP methods, Xitoring provides flexibility in monitoring web applications based on the specific needs and requirements of the user.

SSL

The SSL check box as it's clear from the name forces Xitoring request to try to connect to the client's endpoint using SSL and will not access plain connections, it is the best way to make sure that your endpoint is communicating using only SSL .

Params

This section is for users that want to send different parameters to their endpoint to make sure everything works fine. Xitoring provides two ways to get the parameters from the user. so the user can enter the parameters in raw mode or enter them one by one in the key/value mode.

Header

Xitoring's HTTP(S) checks allow users to send custom headers in their requests. The following is a list of commonly used headers:

• Authorization: Used to send authentication credentials to the server.
• Accept: Indicates the type of content the client can accept from the server.
• Accept-Encoding: Indicates the compression algorithm the client can accept from the server.
• Cache-Control: Provides directives for caching mechanisms in both requests and responses.
• Connection: Controls whether the connection is kept open or closed after the request/response is completed.
• Cookie: Used to send previously-stored cookies back to the server.
• User-Agent: Identifies the client making the request, typically used by servers to tailor the response based on the client's capabilities.
• Content-Type: Indicates the format of the data being sent in the request body. By allowing users to send custom headers in their requests, Xitoring enables the monitoring of web applications with specific header requirements, such as authentication or content negotiation.

Group

The next option is Group. Xitoring has an advanced Group/Sub-Group management system so users can sort and organize Checks and Server, For example, some users organize their assets based on location and create Groups for countries and Sub-Groups for Cities. it can help see the records for a specific part of your assets easily.

Using the gear icon next to the title, you can access the Group management mini tool, the user can create, delete and edit groups and sub-groups.

Interval

Interval sets how often probing nodes will make their requests to your URL, 1 minute will provide the most detailed, accurate, reports and notifications. Also For some services, the Higher interval makes more sense. So you can configure Xitoring to Check your HTTP(S) Check status every minute or you can make it check every 10 minutes.

Trigger Options

The most important part of creating a check is Trigger options Triggers will define the incident status of a Check.

Notification Roles

In this section user can assign one or more notification roles to this check trigger, it will define who gets notified and how every time this check has an incident. For Example, the user has two notification roles one for the IT team that contains the Email and phone numbers of the team members, and one notification role for the CTO. Users can configure the trigger to notify the IT team and the CTO in time of an incident using Email and SMS notifications.

Fault Tolerance

Fault tolerance is a time value (Minutes) that determines how much stress can a system take before it's entering a critical state. If you set FT to 5 we send an incident report when the incident is existing for 5 minutes.

Condition

This is the most important part of an HTTP(S) Trigger setup, users can set multiple different conditions to make the trigger more accurate.

For example, the user can set a condition to say that the HTTP(S) check response Should Contain a certain status code or even a word.

TIP

The Run Test button can be used to either determine the current status of the check or make sure that the entered information is correct.