Check Types & Execution Model

Overview

Quismon supports several check types, each with different execution characteristics. Understanding these differences is crucial for designing effective monitoring strategies.

Available Check Types

Multi-Step Checks vs Dependent Checks

Multi-Step Checks

Execution Model: All steps execute sequentially on a single checker node within the same session.

┌─────────────────────────────────────────────────────────────┐
│                   Single Checker Node                        │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│  │  Step 1  │───▶│  Step 2  │───▶│  Step 3  │              │
│  │  Login   │    │ Get Data │    │ Verify   │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│       │               │               │                      │
│       └───────────────┴───────────────┘                     │
│                   │                                          │
│            Variables flow between steps                      │
│            (auth tokens, session cookies, etc.)              │
└─────────────────────────────────────────────────────────────┘

Characteristics

• Steps share context (cookies, extracted variables)
• Each step can pass data to the next step
• All steps must complete on the same checker
• If one step fails, subsequent steps may not run (configurable)

Use Cases

• Login flows (authenticate → access protected resource)
• API chains (get ID → fetch related data)
• Shopping carts (add item → verify cart → checkout)
• Any workflow requiring session state

Example

{
  "type": "multistep",
  "config": {
    "steps": [
      {
        "name": "Login",
        "type": "https",
        "config": { "url": "https://api.example.com/login", "method": "POST" },
        "extracts": { "token": { "jsonpath": "$.access_token" } }
      },
      {
        "name": "Get Profile",
        "type": "https",
        "config": {
          "url": "https://api.example.com/profile",
          "headers": { "Authorization": "Bearer {{token}}" }
        }
      }
    ],
    "fail_fast": true
  }
}

Dependent Checks

Execution Model: Independent checks that can be distributed across multiple checker nodes and regions. One check's failure can trigger another check to run.

┌──────────────────┐         ┌──────────────────┐
│  Checker Node A  │         │  Checker Node B  │
│  (na-east-ewr)   │         │  (eu-central-fra)│
│                  │         │                  │
│  ┌────────────┐  │         │  ┌────────────┐  │
│  │  Check 1   │  │         │  │  Check 2   │  │
│  │  API Health│  │         │  │  Database  │  │
│  └────────────┘  │         │  └────────────┘  │
│        │         │         │        │         │
└────────│─────────┘         └────────│─────────┘
         │                            │
         │    Check 1 FAILS           │
         │         │                  │
         │         ▼                  │
         │  ┌────────────────┐        │
         └─▶│ Trigger Check 3│◀───────┘
            │  (Dependent)   │
            │  Investigate   │
            └────────────────┘
                    │
            Runs from ITS regions,
            not Check 1's regions

Characteristics

• Each check runs independently
• Checks can have different region configurations
• depends_on creates execution dependencies
• Dependent checks run from their own regions, not the parent's

Use Cases

• Staged monitoring (check API → if down, check database)
• Root cause analysis chains
• Regional failover detection

Regional Execution

Simultaneous Regions

When simultaneous_regions is true:

Time: 0s    ┌────────────┐  ┌────────────┐  ┌────────────┐
            │ na-east-ewr│  │eu-central- │  │ap-southeast│
            │  Checker   │  │   fra      │  │   -sin     │
            └────────────┘  └────────────┘  └────────────┘
                  │               │               │
                  ▼               ▼               ▼
            All regions check simultaneously

Staggered Regions

When simultaneous_regions is false:

Time: 0s    ┌────────────┐
            │ na-east-ewr│
            └────────────┘
                  │
Time: 10s         │         ┌────────────┐
                  └────────▶│eu-central- │
                            │   fra      │
                            └────────────┘
                                  │
Time: 20s                         │         ┌────────────┐
                                  └────────▶│ap-southeast│
                                            │   -sin     │
                                            └────────────┘

Staggered execution spreads load over time and can detect transient issues.

Check Budget Calculation

Each regional check execution counts toward the hourly budget:

Formula: (3600 / interval_seconds) × number_of_regions = checks_per_hour

Best Practices

When to Use Multi-Step

• ✅ Workflow requires session state
• ✅ Steps must share cookies/tokens
• ✅ Sequential user journey simulation
• ❌ Independent endpoint monitoring

When to Use Dependent Checks

• ✅ Root cause analysis chains
• ✅ Different regions for different checks
• ✅ Staged alerting (warning → critical)
• ❌ Need to pass variables between checks

When to Use Simultaneous Regions

• ✅ Detect regional outages quickly
• ✅ Global availability monitoring
• ❌ Trying to conserve check budget

When to Use Staggered Regions

• ✅ Spread load over time
• ✅ Reduce budget usage impact
• ✅ Detect transient issues over time