Availability Monitoring for HTTP Endpoints
Maintaining the availability and uptime of your services is crucial for delivering seamless experiences to customers and ensuring business continuity. Even with robust infrastructure strategies like multi-zone deployments or redundant DNS setups, proactive monitoring remains essential to detect and address issues before they impact users.
With this template, you can automate availability monitoring by sending periodic HTTP requests to your endpoints and validating responses. It checks for successful responses, retries upon transient failures, and triggers alerts through various channels when downtime is detected.
Conductor features used
This template utilizes the following Conductor features:
How to use the template
- Import the template
- Understand the workflow logic
- Set up providers for sending notifications
- Run workflow
Import the template
To import the template:
- Go to Template Explorer from the left navigation menu on your Conductor cluster.
- Choose Availability Monitoring for HTTP(S) Endpoints and select Import.
- Rename the workflow and task names. For example, rename the workflow as “Monitor-HTTP-Endpoint-Availability_your_name”.
- Select Save.
The workflow is now imported and ready for use.
Understand the workflow logic
This section explains the workflow logic and how to execute it.
Workflow inputs:
- endpoint_url–The HTTP(S) endpoint to be monitored using the workflow.
- notification_type–The medium for sending notifications if the endpoint is down. Supported values are:
- SMS
- SLACK
- PAGERDUTY
- notification_to–The email or phone number to which the notification is sent if the notification_type is SMS or EMAIL.
- notification_from–The email or phone number to be displayed as the notification originator if the notification_type is SMS or EMAIL.
Example input payload for sending an SMS alert using Twilio:
{
"notification_type": "SMS",
"endpoint_url": "https://example.com/",
"notification_from": "14XXXXXXXXX",
"notification_to": "12XXXXXXXX"
}
Workflow logic:
- The workflow begins with an HTTP task that sends a GET request to the specified endpoint.
- In the next step, the Inline task retrieves the current timestamp from the server.
- Next, the Switch task evaluates the output of the previous HTTP task to determine if the response indicates a success or failure.
- If a 200 OK response is returned, the Switch task directs the execution via the defaultCase, ending the workflow.
- For any other response or failure (e.g., DNS error), the Switch task sends execution to the FAILED path.
- The failure path invokes a Sub Workflow, namely Notify-Channels, which sends a failure notification via the specified channel.
- This workflow begins with a Switch task confirming that the notification_type is a supported format.
- Depending on the notification_type, the corresponding switch case executes and sends the notification through the specified channel.
Set up providers for sending notifications
This template sends notifications using the following providers:
- Twilio–Required for SMS notifications.
- SendGrid–Required for email notifications.
- PagerDuty–Required for PagerDuty alerts.
- Custom Slack webhook–Required for Slack notifications.
Configure your preferred provider and add the required credentials as secrets in Conductor.
Notification Type | Provider | Credentials to be saved as Secret in Conductor |
---|---|---|
SMS | Twilio | The account ID of the Twilio account.
|
Sendgrid | The API key from Sendgrid.
| |
SLACK | Slack | Slack Webhook URL.
|
PAGERDUTY | Pagerduty | Routing key for sending messages to Pagerduty.
|
The workflow is already configured with the above-mentioned secret names, so no further modifications are needed.
- Ensure the credentials are correctly set before running the workflow to avoid errors. The workflow will fail if any of the parameters are incorrect or unreadable.
- If you use different names for the secrets, ensure the Notify-Channels workflow is updated with the correct secret names. Failure to do so will result in an unauthorized error.
Run workflow
You can run the workflow in different ways.
- Using Scheduler
- Using Conductor UI
- Using API
The Scheduler allows you to set a predefined cadence for running a workflow. Once the schedule is configured, Conductor will automatically invoke the workflow at the specified intervals, requiring no further action from the user.
To schedule workflows:
- Go to Definitions > Scheduler from the left navigation menu on your Conductor cluster.
- Select + Define Schedule.
- Provide a schedule name, select the workflow name and version, and set the schedule using the cron expression.
- Select Save > Confirm.
This saves the Schedule definition, and the workflow is now automated to run at specific cadence. Refer to Scheduling Workflows documentation for more details.
To run the workflow using Conductor UI:
- From your imported workflow, go to the Run tab.
- Enter the Input Params.
- Select Run Workflow.
Use the following endpoint to start the workflow:
POST /api/workflow/{name}
Refer to the Start Workflow Execution API reference for more information.
Workflow output
The workflow output includes details of the notification sent to the respective platform.
Examples
- PagerDuty
- Slack
- Twilio
- Sendgrid
Example for a notification received in PagerDuty:
Example for a notification received in a Slack channel:
Example for a notification received as SMS via Twilio:
Example for a notification received as an email via Sendgrid:
This template provides a starting point for customizing the workflow to your needs. You can add additional steps, such as logging events, or add a different provider (like Opsgenie for incident notifications) to suit your business requirements.