​
Uptime Monitoring

Metoro’s Uptime Monitoring feature allows you to monitor the health and availability of your services. You can configure monitors to regularly check your HTTP endpoints or TCP ports and track their response times and status.

​
Monitoring Types

Metoro supports two types of uptime monitoring:

  1. HTTP Endpoint Monitoring: Check the health of web applications, APIs, and other HTTP services
  2. TCP Port Monitoring: Verify network connectivity to services by checking if TCP ports are open

​
Features

  • Multiple Monitor Types: Support for both HTTP and TCP monitoring
  • Flexible Status Code Matching: Support for exact matches (e.g., 200), wildcards (e.g., 2XX), and multiple patterns (e.g., 200,201,X04) for HTTP monitors
  • Response Body Validation: Validate HTTP response bodies against regular expressions
  • Custom Headers: Add custom headers to your HTTP requests
  • Multiple HTTP Methods: Support for GET, POST, PUT, PATCH, and DELETE
  • Configurable Check Frequency: Monitor endpoints from every minute to every hour
  • Metric Generation: Automatic generation of response time and status metrics

​
Getting Started

  1. Navigate to the Settings page in your Metoro dashboard
  2. Select the “Integrations” tab
  3. Click “Add Monitor” in the Uptime Monitoring section

You must have create permissions for the integration resource to add a monitor, update permissions for the integration resource to edit a monitor and delete permissions for the integration resource to delete a monitor.

​
Configuration Options

​
Basic Settings

  • Name: A descriptive name for your monitor
  • Check Type: Choose between HTTP or TCP monitoring
  • Check Frequency: How often to check the endpoint

​
HTTP Check Configuration

When configuring HTTP monitors, you’ll need to specify:

​
Endpoint Settings

  • Endpoint URL: The complete URL to monitor (including http:// or https://)
  • HTTP Method: The HTTP method to use (GET, POST, PUT, PATCH, DELETE)

​
Status Code Validation

You can specify expected status codes using:

  • Exact codes: 200
  • Wildcards: 2XX (any 2XX status) You must use uppercase for wildcards.
  • Multiple patterns: 200,201,X04

Examples:

  • 200: Expect exactly 200 OK
  • 2XX: Accept any successful response
  • X00: Accept any status code ending in 00
  • 200,201,202: Accept any of these specific codes

​
Response Body Validation

You can optionally validate the response body using regular expressions. This is useful for:

  • Ensuring specific content is present
  • Validating response format
  • Checking for error messages

Example patterns:

  • .*"status":"healthy".*: Check for a healthy status in JSON
  • ^OK$: Expect exactly “OK”
  • version: [0-9]+\.[0-9]+\.[0-9]+: Match a semantic version number

​
Headers

You can add custom headers to your requests. Some common use cases:

  • Authentication tokens
  • API keys
  • Content type specifications

For POST/PUT requests, the Content-Type header is automatically set to application/json.

​
Request Body

For POST, PUT, and PATCH methods, you can specify a request body to send with each check.

​
TCP Check Configuration

When configuring TCP monitors, you’ll need to specify:

​
Connection Settings

  • Host: The hostname or IP address to monitor
  • Port: The TCP port number to check

TCP monitoring works as follows:

  • A simple TCP connection attempt is made to the specified host and port
  • The connection has a 10-second timeout by default
  • If the connection succeeds, the check passes with a status code 200
  • If the connection fails or times out, the check fails with an error message

TCP checks are perfect for monitoring basic connectivity to services like databases, mail servers, or any other TCP-based service.

​
Metrics

Each monitor automatically generates two metrics:

  • Response time metric: uptime_monitor_[metric_name_base]_response_time
  • Status metric: uptime_monitor_[metric_name_base]_status

These metrics can be used in dashboards and alerts to monitor your endpoints’ health.

​
Uptime Monitor Logs

All uptime monitoring results are logged and can be viewed in the logs view. The logs are published with:

  • Service name: uptime-monitor
  • Environment: metoro-internal

For successful checks:

  • Log line: Uptime check succeeded
  • Attributes include: status code, response body, endpoint pinged, latency

For failed checks:

  • Log line: Uptime check failed
  • Attributes include:
    • Error field explaining why the check failed
    • Status code (if received)
    • Expected vs actual response body
    • Endpoint pinged
    • Latency (if request completed)

​
Status Pages

Status pages provide a way to communicate your service’s health and incidents to your users. You can create multiple status pages for different audiences or services.

​
Creating a Status Page

  1. Navigate to the Settings page in your Metoro dashboard
  2. Select the “Status Pages” tab
  3. Click “Create Status Page”

​
Configuration Options

  • Name: A descriptive name for your status page
  • Slug: The URL-friendly identifier for your page (e.g., status.yourdomain.com)
  • Access: Choose between public or private access
    • Public: Anyone with the URL can view the status page
    • Private: Only authenticated users can view the page
  • Branding:
    • Logo: Upload your company logo
    • Favicon: Custom favicon for the status page
    • Theme colors: Customize the look to match your brand

​
Components

Components represent different parts of your service that you want to monitor. For each component:

  1. Name: Name of the service component
  2. Description: Optional description of what the component does
  3. Group: Optionally group related components together
  4. Monitors: Associate uptime monitors with this component
    • Status will automatically update based on monitor results
    • Multiple monitors can be assigned to a single component

​
Suggested Visualizations

  • Uptime Success: Create a stat chart using uptime_monitor_[name]_status{status="success"} with an aggregation sum and last as the reduction function.
  • Uptime Failure: Create a stat chart using uptime_monitor_[name]_status{status="failure"} with an aggregation sum and last as the reduction function.
  • Response Time Trends: Line chart of uptime_monitor_[name]_response_time over time

​
Best Practices

  • Check logs immediately after creating a new monitor to verify it’s working as expected
  • Create dashboards that show both status and response time for critical services
  • Set up alerts for all important uptime monitors
  • Adjust monitor frequency based on the importance of the service; critical services should be checked more frequently

​
Learn More

For detailed information on specific monitoring types: