Temperstack
Main WebsiteFeaturesPricingBlogAbout usRequest a Demo
  • Overview
    • What is Temperstack?
    • Use Cases
  • User Managment
    • Getting started as Admin
      • Inviting Users
      • Mapping multiple services to a Team
      • Single Sign-On (SSO)
      • Customising ALCOM Audit & scanning
    • Getting Started as a User /Responder
    • Managing profile & contact details
  • Integrations
    • Integrating your Observability tools
      • Setting up AWS Integration
        • Multiple AWS Account Integration
        • IAM Setup Guide
          • Creating IAM User: Temperstack with Policy
          • Creating IAM Role: Temperstack with Policy
      • Setting up Microsoft Azure Integration
        • Creating Access for Temperstack in Azure
      • Setting up Google Cloud Platform Integration
        • Creating Access for Temperstack in GCP
      • Setting up Datadog Integration
        • Creating Access for Temperstack in Datadog
        • Managing resources with Datadog
      • Setting up NewRelic Integration
        • Creating Access for Temperstack in NewRelic
        • Managing resources with New Relic
      • Setting up Splunk Integration
        • Creating Access for Temperstack in Splunk
        • Managing resources with Splunk
      • Setting up Appdynamics Integration
        • Creating Access for Temperstack in Appdynamics
        • Managing resources with Appdynamics
      • Setting up Dynatrace Integration
        • Creating Access for Temperstack in Dynatrace
        • Managing resources with Dynatrace
      • Setting up Oracle Cloud Infrastructure
        • Creating Access for Temperstack in OCI
    • Integrating Custom Alerts & Other Alerting sources
      • Webhook Integration
      • Ingesting Emails as alerts
      • Integrating alert listeners from other observability tools
  • Alert routing & Response Managment
    • On-call scheduling and Escalation Policies
    • Setting up Services
    • Alert notification channels
      • Integrating Slack channels
      • Integrating MS Team
    • Mapping resources to Services
      • Rule based resource to Service Mapping
      • Using AI suggested mapping rules
    • Testing Alerting and Notifications
    • Responding to Alerts
  • Monitoring
    • Setting up and maintaining Comprehensive alerting
      • Alerting Templates- metrics & customisation
      • ALCOM and identifying monitoring gaps
      • Programmatically setting up missing alerts in your Observability tool
      • Alert noise Reduction & Optimisation
  • Uptime Monitoring
    • Real time Availability Monitoring
  • Incident analysis & communication
    • External and Internal service Status Pages
      • Instruction to migrate subscribers from Statuspage
  • AI-Powered Issue Resolution
    • AI powered contextual Runbooks
    • Incident command - alert grouping by incident
    • AI Powered Root cause Identification
  • Reporting & Governance
    • Temperstack Dashboard
    • SLO Dashboard
    • MTTA MTTR
  • Billing & Help
    • FAQs
    • Support
Powered by GitBook
On this page
  • Features of Temperstack Availability Monitoring
  • Adding a New Endpoint
  • Managing Endpoints
  1. Uptime Monitoring

Real time Availability Monitoring

Last updated 3 months ago

Temperstack offer Realtime availability monitoring (ping monitoring) along with response time trends This can be used to raise alerts on API end point availability.

Features of Temperstack Availability Monitoring

Endpoint Monitoring

Temperstack availability monitoring allows you to set up ping monitoring for various endpoints. This helps you keep track of your services' availability and performance.

Headers and Parameters

You can customize the requests used for ping monitoring by modifying headers and parameters. A key point to note is that the default User-Agent in headers is "TempetstackPing", but this can be changed in the headers section if needed.

Authentication

Authentication is an optional feature that allows you to modify requests with authentication payloads. This authentication information will be added to the request header, and will be overridden if the request header already contains an authentication payload. Temperstack Synthetics supports several authentication methods:

  1. Basic Authentication

  2. Bearer Token Authentication

  3. API Token Authentication

  4. JWT Authentication (dynamic)

For static authentication methods (Basic, Bearer Token, API Token), the provided values are used consistently for each ping monitor request. JWT authentication is unique in that it dynamically generates a JSON Web Token for each request, incorporating user-provided details along with standard claims like "iat" (issued at), "exp" (expiration), and "nbf" (not before).

Adding a New Endpoint

To add a new endpoint for monitoring, follow these steps:

  1. Log in to the Temperstack dashboard

  1. Navigate to Resources - Temperstack Synthetics

  1. Click on "Add New"

  1. Enter the Endpoint name

  1. Select the request method from the dropdown menu:

    • GET: Retrieve data

    • POST: Submit data to be processed

    • PUT: Update existing resource

    • DELETE: Remove a resource

    • PATCH: Partially modify a resource

    • HEAD: Similar to GET but retrieves headers only

    • OPTIONS: Describe communication options for the target resource

  1. Map the endpoint to a service

  1. Enter the Endpoint URL

  1. Specify the expected response code

  1. Set the check interval in minutes

  1. Define the request timeout in seconds

  1. Choose the authentication method from the dropdown

  1. Add request parameters (key-value pairs)

  1. Add request headers (key-value pairs)

  1. Specify any required response body text/JSON

There are three available methods for checking the results of the response body of a request:

To explain the following examples, let’s consider a sample endpoint that returns the following JSON upon execution:

{
  "api_version": "v22.02",
  "runtime": 123.456,
  "latest_run": {
    "state": "FAIL",
    "timestamp": 1738059006,
    "invoked_by_system": true
  }
}

Complete JSON Match

In this method, the response body of the ping request is compared directly with the provided input JSON. For the ping to be considered successful, the response must match exactly.

If the response body field is left blank, the request is automatically considered successful, and no response body matching is performed.

Partial JSON Match

This method allows partial matching of the response body. It looks for exact matches of primitive types (numbers, booleans, strings, null) and recursively checks objects and lists in the JSON structure.

Let’s assume you want to validate the sample endpoint but ignore dynamically generated fields that are not relevant to the status of the endpoint, such as "runtime" or "timestamp".

Since the "state" in "latest_run" from the response (FAIL) does not match the expected input (SUCCESS), this ping will be marked as a failure.

Regex Match

For example, suppose the "state" field in "latest_run" can have multiple valid values, such as ["INITIALIZING", "RUNNING", "SUCCESS", "FAIL"]. To allow all acceptable states except "FAIL"

This regex pattern allows the monitoring system to accept responses where the "state" is "INITIALIZING", "RUNNING", or "SUCCESS". If the "state" is "FAIL", the ping will be marked as a failure.

You can also use the Test Regex button to validate your regex before submitting it, along with a sample input. Note: The sample input is not stored.

  1. Request Body for HTTP Methods

When using POST, PUT, or PATCH HTTP methods, you can include a request body with your request. The request body allows you to send additional data as part of your HTTP request.

  1. Alarm Settings

    Alarm on Y Failures out of X checks: This setting specifies the number of failed checks (out of a total of 5 checks) required to trigger the alarm. For example, the alarm will be triggered if there are 3 failures out of the last 5 checks. It also determines the total number of checks considered for the alarm trigger condition.

The explanation provided an example - if the setting is '2/3', it means the alarm will be raised only when at least 2 pings were down in the last 3 checks.

This allows the user to configure the alarm settings more flexibly, rather than simply triggering an alarm on the first failure. It helps to avoid false alarms caused by temporary or intermittent failures, and only raise the alarm when there is a more sustained issue with the monitored endpoint.

The goal is to strike a balance between detecting real problems early, while avoiding unnecessary alerts for transient failures that may not require immediate intervention.

  1. Click "Save Changes"

Managing Endpoints

  • To disable an endpoint temporarily, click the toggle button under "Actions" for the desired endpoint and turn off the toggle.

  • Bulk service mapping is available by selecting multiple endpoints and clicking the "Map to Service" button in the top right corner.

  • Response Time by Endpoint

    • Line graph showing response times for different service endpoints over time.

    • Includes options to view historical data (e.g., last 3 hours , 6 hours, 24 hours, 3 days, 7 days, 30 days).

    • Displays key statistics like uptime percentage and average response time.

This method provides the most flexibility by parsing the response body using Python's regex engine. The regex pattern determines whether the response is considered successful.

re
Complete JSON Match
Partial JSON Match
Regex Match
User interface for specifying the expected response body in JSON format.
Enter the complete JSON response here to validate exact matches.
Use this section to enter the specific fields you want to validate.
Specify Regex patterns that will be validated using request JSON
Request Body Configuration Interface taken as a JSON
Screenshot of a response body input field where users can enter a JSON object for exact matching in a request validation process.
Screenshot of an input field in the web UI where users can specify a JSON structure for partial matching against a request’s response.
Combined screenshots of a web interface with an input box where users can enter a JSON response for regex-based validation.
Screenshot of the monitoring interface showing text input area for Request Body