checkly-groups_skill

Overview

This skill organizes Checkly checks into CheckGroups to apply shared configuration, inheritance, and logical grouping. It helps manage multiple related checks by setting group-level defaults like locations, frequency, tags, environment variables, and alert channels. Use it to enforce consistent settings and reduce duplication across checks.

How this skill works

Define CheckGroup objects with common properties (name, activated, locations, frequency, tags, environmentVariables, alertChannels). Assign checks to a group so they inherit group settings; check-level properties override group defaults. Group settings sit above global defaults but below explicit check properties, enabling hierarchical configuration.

When to use it

• Managing many checks that share locations, frequency, or environment variables
• Setting group-level alerting or notification channels for a team or service
• Reducing duplication when multiple checks target the same API, service, or environment
• Organizing monitoring by service, team, or criticality level
• Applying consistent tagging and metadata across related checks

Best practices

• Keep group scopes narrow and logical (e.g., service, environment, or criticality) to avoid accidental overrides
• Use environment variables at the group level for shared endpoints or credentials, then reference them in checks
• Assign alert channels at the group level for team-specific routing and escalation
• Prefer check-level overrides only when a single check requires a different behavior
• Document group purpose and intended members to prevent configuration drift

Example use cases

• Create an "API Monitoring" group with locations, frequency 5, and API_BASE_URL environment variable for all backend checks
• Define a "Critical Services" group with frequency 1 and an email alert channel to escalate high-impact failures
• Organize checks by team: create a group per team with team-specific alert channels and tags for cost and ownership tracking
• Use hierarchical settings to let global defaults apply generally while groups tighten frequency and locations for particular services
• Assign synthetic browser checks and API checks to different groups to control runtime locations and schedules separately