Check Types

LIVCK offers various check types to monitor the availability and performance of your infrastructure. Each check type is designed to cater to different monitoring requirements. Here are examples of commonly used check types:

TCP Check

The TCP check monitors the availability of a TCP service on a specific destination IP and port. It verifies that the specified service is reachable and responsive. Here's an example configuration for a TCP check:

• Name: DNS Server
• Monitor Category: Infrastructure
• Destination IP / Port: 1.1.1.1
• Destination Port: 53
• Description: Domain Name System
• Interval: 1
• Interval Unit: Minute

HTTP Check

The HTTP check allows you to monitor the availability and performance of a web server or website. It can verify the response status codes, check for specific content in the response, and more. Here's an example configuration for an HTTP check:

Allgemein

• Name: Homepage
• Monitor Category: Infrastructure
• URL: https://livck.com
• Description: Website
• Interval: 1
• Interval Unit: Minute

Http

• Method: GET/POST
• Accepted Status Codes: [Add acceptable codes]
• Rejected Status Codes: [Add rejected codes]
• Accept 2xx Statuses: [Checkbox] Accept all status codes from 200 to 299
• Skip SSL/TLS Validation: [Checkbox] When the SSL certificate is invalid, the monitor is marked as unavailable
• Allow Redirects: [Checkbox] Allow redirects to other Websites / URLs

Headers

• Header 1: Authorization: Basic 34i3j4iom2323==
• [Add additional headers as needed]

Authentication

• Username: Administrator
• Password: **********

Request

• Body: field1=LIVCK&field2=Monitoring

Response

• Response: API=OK

Manual Check

The Manual check allows you to create custom checks where the status is updated manually. It is useful for monitoring activities that cannot be automated or require human intervention. Here's an example configuration for a manual check:

• Name: DDoS Protection
• Monitor Category: Infrastructure

Infrastructure

• Status: OK/Vorfall
• Beschreibung: Firewall

Updating via Third-Party Software

Tip: If you're using third-party monitoring software or automation tools, you can update the Manual Check status programmatically using the LIVCK API v2.

Requirements:

1. API Token - Generate an API token in your user profile

   • Navigate to /user/profile
   • Create a new API token
   • Copy and securely store the token

2. API Documentation - Access the full API reference at https://livck.com/r/api-docs

Use Cases:

• Update monitor status from external monitoring systems
• Integrate with custom scripts and automation
• Modify all LIVCK resources programmatically
• Synchronize status with third-party platforms

With API tokens, you have full control over all LIVCK resources, allowing seamless integration with your existing monitoring infrastructure.

Heartbeat Check

The Heartbeat check monitors whether external services or applications are actively sending periodic "heartbeat" signals to LIVCK. This is a passive monitoring approach where services report to LIVCK instead of LIVCK checking them.

How It Works

When you create a Heartbeat monitor, LIVCK generates a unique URL endpoint (example):

https://status.example.com/api/v3/health-check/X3jqostsxwJj6arG

Note: This is an example URL. Your actual URL will be different and displayed in the LIVCK interface after creating the monitor.

Your service, application, or script must call this URL at the configured interval (e.g., every minute). If LIVCK doesn't receive a heartbeat signal within the expected timeframe, the monitor is marked as down.

Use Cases

Heartbeat monitoring is ideal for:

• Cron Jobs - Verify scheduled tasks are running
• Backup Jobs - Ensure backups complete successfully
• Laravel Scheduler - Monitor scheduled artisan commands
• Batch Processes - Track long-running jobs
• Services Behind Firewalls - Monitor services not accessible to LIVCK
• Internal Applications - Check services that can't be reached from outside

Configuration

Example Setup:

• Name: Daily Backup Job
• Monitor Category: Infrastructure
• Expected Interval: 1 minute (60 seconds)
• Grace Period: Additional time buffer before marking as down
• Description: MySQL backup verification

Installation Methods

After creating a Heartbeat monitor, LIVCK provides multiple ways to integrate it:

Method 1: Automated Installation (Recommended)

LIVCK generates an installation script you can run directly on your server:

curl https://status.example.com/heartbeat-install/X3jqostsxwJj6arG | bash

This script automatically:

• Installs the heartbeat as a cron job
• Configures the correct interval
• Sets up the necessary permissions

Method 2: Manual Cron Job

Add a cron entry manually:

# Call heartbeat every minute
* * * * * curl -s https://status.example.com/api/v3/health-check/X3jqostsxwJj6arG > /dev/null 2>&1

Method 3: From Application Code

PHP (Laravel):

use Illuminate\Support\Facades\Http;

Http::get('https://status.example.com/api/v3/health-check/X3jqostsxwJj6arG');

Python:

import requests
requests.get('https://status.example.com/api/v3/health-check/X3jqostsxwJj6arG')

Node.js:

const axios = require('axios');
axios.get('https://status.example.com/api/v3/health-check/X3jqostsxwJj6arG');

Shell Script:

#!/bin/bash
curl -s https://status.example.com/api/v3/health-check/X3jqostsxwJj6arG

Important Notes

• The heartbeat URL must be called at the configured interval (with minimal deviation)
• Each Heartbeat monitor has a unique URL - keep it secure
• If the URL isn't called within the expected interval + grace period, the monitor fails
• Perfect for monitoring services that aren't directly accessible from LIVCK's server

Display Status Override

You can manually override the displayed status of any monitor — independent of the actual monitoring result. This is useful when you know a service is degraded but the automated check hasn't detected it yet, or when you want to signal planned maintenance.

Configuration

On the monitor edit page (HTTP, TCP, HealthCheck, Manual), you'll find:

Available Options

Effect on Incident Bars

In Settings, the option "Display status affects incident bar colors" (enabled by default) controls whether the override affects incident bar colors:

When set to Maintenance, all bars are blue — even if incidents occur during that time. This signals to visitors that downtime is expected and planned.

When the option is disabled, normal colors apply: green (no incident), yellow (incident < 1h), red (incident > 1h).

Effect on Global Status

The override feeds into the global status calculation of the status page. A single monitor set to "Major Outage" is enough to set the overall status to "Major Outage".

Priority: Offline > Partly > Degraded > Maintenance > Online

Status Icon Legend

On the public status page, a legend is displayed that explains all possible status states:

The legend is displayed below the status header, above the monitors. It shows colored dots with labels and provides detailed descriptions on hover. The layout is responsive and supports both light and dark mode.