How Checkmk-Powered Alerting Works Inside CloudMint

Checkmk is a serious, capable monitoring engine — and like most serious monitoring engines, its native vocabulary (WATO, Livestatus, active checks, CRIT/WARN/UNKNOWN) is not something you want your on-call engineer parsing at 2am. CloudMint runs on top of it, but nothing in the default screens ever says "WATO." Here's what that actually buys your team.

Real health checks and synthetic checks, in one inbox

Host and service health comes from Checkmk itself. Synthetic checks — HTTP, TCP, DNS, ICMP, TLS certificate expiry, and full browser-journey checks — run on their own schedule and can be created from the Monitoring screen, from a specific VM's Health tab, or pointed at an external endpoint you don't even host. Both feed the same inbox, so "is my VM healthy" and "is my checkout flow working" get answered in the same place instead of two different tools.

Plain language, not engine vocabulary

Whatever the source, the result gets translated before a human ever sees it:

• CRIT / WARN / OK / UNKNOWN becomes Critical / Warning / Healthy / No data
• Acknowledge becomes "I'll look at it"
• Downtime becomes "Pause alerts", with plain options: 1 hour, 4 hours, or until tomorrow
• An Active check is just "Watch this website / port / DNS / ping / certificate / user journey"

This translation isn't cosmetic. It's the difference between a monitoring tool operators tolerate and one they actually use without a manual open in another tab.

An inbox that doesn't cry wolf

A single failed check doesn't page anyone. Checks only escalate to Critical after they've stayed unhealthy for a bit — a short, flappy blip stays a Warning instead of triggering a false alarm. That one piece of judgment is most of the difference between an alert inbox people trust and one people mute.

Tickets that don't spam your Jira project

A health change doesn't blindly become a ticket. It's checked against your alert policy first — is it paused, has a severity actually been configured for this, is it still inside a cooldown window — so a flapping check can't open five tickets in ten minutes. If a ticket already exists for the issue, CloudMint adds a comment instead of opening a duplicate, and it can automatically close that ticket out when things recover. The net effect: your Jira board reflects real, current problems instead of a backlog of noise someone has to triage by hand.

One timeline, not three

Every health change is recorded alongside VM power events and cost alerts — so "what happened and when" lives in one place, not scattered across a monitoring tool, an inbox, and Jira's own history.

And a human can always skip the queue

Automation is the default path, not the only one. A "Create ticket" action is always available on any check, so someone can open a Jira issue the moment they notice something — without waiting on a threshold.

Why route it through one alert policy at all

The alternative — Checkmk notifications going one way, synthetic-check alerts going another, someone manually filing tickets for what falls through — is exactly the fragmentation this is built to remove. One policy, one inbox, one place to tune sensitivity, regardless of whether the evidence came from a real host or a synthetic browser journey.