# Website POST Configuration Guide on the Elven Platform With **Website POST** from the **Elven Platform**, you can monitor your services in a simple and efficient way using the **POST method** of the **HTTP protocol**. This feature is perfect for tracking the performance of **APIs**, **forms**, or any other resource that requires **data submission**. The idea is to make your life easier: you can configure **automatic checks**, receive **real-time alerts**, and even set rules for **automatic incident creation** whenever something goes off track. All of this ensures you're aware of any issues before they impact your users. And the best part: there's no need to install agents in your infrastructure. **Website POST** uses **Elven Platform’s external agent network**, which performs monitoring externally, just like your services are accessed in real-world scenarios. In other words, you don’t need to create environments, configure clouds, or worry about setting up an agent. You can simply configure your monitoring in a **faster**, **lighter**, and **more flexible** way. Let’s talk a bit about the **HTTP POST method**, an essential tool when it comes to **sending data to the server**. Unlike the **GET method**, which only retrieves information, **POST** sends data in the **body of the request**, allowing for more complete interactions with services. This means that by using **POST**, you can **create new resources**, **update information**, or **trigger specific actions** on the server. It’s this flexibility that makes **POST** so powerful, especially when dealing with more complex services like **APIs** that require **authentication**, **dynamic parameters**, or **backend business logic**. In the context of **monitoring**, it becomes a valuable ally, as it allows you to **simulate real interactions** with your systems—testing not only if they are online, but also if they are **responding correctly** to expected operations. {% embed url="" %} ## **Accessing the Website POST** * Navigate to the **main menu** and click on **Services Hub**. * Under **Internet Services**, select the **Website POST** item. ## **Resource Monitoring** **Monitoring the availability** of your services has never been easier. Start by giving a clear name to the resource you want to track (**Resource Name**) to make identification easier. Then, adjust the **interval between checks** (**Interval**) and the **response timeout** (**Timeout**). Select the **cloud** where the monitoring agent is located (**Checkpoint Cloud**), such as **AWS**, and choose the specific **region** (**Checkpoint**), like **N. Virginia**, to ensure maximum accuracy. This setup uses the **default agent** from the **Elven Platform**, eliminating the need to create a new environment. Add the **Healthcheck URL**, and if needed, configure **advanced options** such as **Skip SSL Validation** or enable **TLS Renegotiation** to meet specific security requirements. Use the available fields to **customize monitoring requests**. For example, include **custom headers** (**Header** and **Value**); to add more than one header, use the **+ button**. Also, define a **Validation String** to validate specific responses. These steps help ensure that the collected data accurately reflects the state of the monitored resource, providing valuable insights and proactive support for your operations. The ability to configure the **HTTP request body type** is essential for sending data to the server properly, meeting the specific needs of each application. You can choose between **"Raw"** and **"application/x-www-form-urlencoded"**. In the first configuration, you can select the **"Raw"** option and define the desired format, such as **JSON**, **XML**, **Plain Text**, **HTML**, or **JavaScript**. This approach offers flexibility for sending structured data, making it ideal for scenarios where complex objects, like **JSON payloads**, need to be transmitted. The configuration is highly versatile, allowing you to customize the data sent in a **direct and efficient** way. In **Post Body**, include the data to be sent in the **POST request**. This data can be in **JSON**, **XML**, or other supported formats. In the second configuration, the **"application/x-www-form-urlencoded"** format is used, which is widely adopted in **web forms**. In this case, the data is organized as **key-value pairs**, making it a lightweight and compatible option for servers expecting information in a more traditional format. This setup is recommended for **simple and quick integrations**. ## **Automatic Incident Opening** You can configure **automatic incident opening** to ensure a quick response to critical issues. To begin, define the **incident severity**, allowing you to prioritize according to urgency. Next, adjust the **Check Interval**, specifying the check frequency in seconds to continuously monitor the resource. This helps ensure you're always one step ahead, detecting problems as soon as they arise. Additionally, select the **team to be notified** whenever an incident occurs and enable the **"Enable to set up automatic incidents opening"** option to ensure the configuration is active. With this setup, the platform automates **incident management**, making the response process faster and more efficient, without the need for manual intervention. This ensures your team is always ready to resolve any issue with speed and precision. ## **Maintenance Window** We also have the **Maintenance Window**, an essential feature for managing **planned maintenance periods** in your application. During this time frame, **checks are temporarily paused**, preventing **monitoring**, **alerts**, and **notifications** from being triggered while you perform updates or adjustments. This allows maintenance to proceed smoothly, without generating unnecessary notifications or false alarms, ensuring your operations continue in an orderly manner without unexpected interruptions in **performance reports**. For example, imagine you need to update the **payment system** of an e-commerce platform by making backend adjustments, such as installing new **security certificates**. To do this, you can configure the **Maintenance Window** for a specific time, such as **12/13/2024, from 2:00 PM to 2:30 PM**. During this period, the **Elven Platform** suspends checks, preventing the monitoring system from logging temporary failures or triggering false alerts. This way, you can make the necessary changes calmly, knowing that the **monitoring system** won’t be affected during maintenance. This approach ensures the update is carried out in an organized manner, without impacting the **user experience** or generating unwanted notifications. ## **Application Opening Hours** You can also rely on the **Application Opening Hours** feature, which allows you to configure your application's **operating hours**. This functionality is essential for customizing **monitoring** based on the periods when your application is actually active, avoiding **alerts** and **notifications** outside of business hours. This way, monitoring becomes more aligned with your business’s real needs, ensuring more accurate **reports** and efficient **management**. For example, imagine your application operates only from **Monday to Friday**, from **9:00 AM to 6:00 PM**. You can configure the **Application Opening Hours** to reflect this schedule by specifying the **working days and hours**. With this setup, the **Elven Platform** automatically disables **checks** outside of these hours, preventing the logging of failures that don’t affect end users and avoiding unnecessary alerts. This approach optimizes **performance analysis**, focusing only on relevant periods and providing a clearer view of your application’s **health** during its **operating hours**. ## **Glossary of Technical Terms** **POST**: An **HTTP protocol method** used to **send data to the server**. It can change the server's state by **creating or updating resources**. **Resource Name**: A **unique name** assigned to the monitored resource to make it easier to identify. **Interval**: The **time**, in seconds, between checks performed by the platform to monitor the resource. **Timeout**: The **maximum time** to wait for a response before considering the check as failed. **Checkpoint Cloud**: The **cloud provider** where the monitoring agent is located, such as **AWS** or other supported clouds. **Checkpoint**: The **specific region** in the cloud where the agent is configured, such as **N. Virginia**. **Healthcheck URL**: The **URL address** used to perform checks on the monitored resource. **Request Body**: The **data sent** in the **body of the POST request** to the monitored resource. **Header**: **Additional information** sent in the HTTP request to **customize** or **authenticate** the monitoring. **Validation String**: A **string of characters** used to validate the response from the resource and ensure it matches expectations. **Skip SSL Validation**: A setting that **bypasses SSL certificate validation** during the check. **TLS Renegotiation**: An option that allows **renegotiation of TLS security protocols** if needed. **Check Interval**: The **frequency**, in seconds, at which the platform performs checks. **Enable to set up automatic incidents opening**: A setting that enables the **automatic creation of incidents** in case of failures. **Incident Severity**: The **priority level** assigned to the incident based on its **criticality**.