Your monitoring tool fires an alert. You check the dashboard. You open your status page. You write an update. You publish it.

That's four steps between "something is broken" and "customers know about it." During an outage, those four steps feel like forty. And the longer it takes, the more support tickets pile up from customers who can see the problem but can't find any acknowledgment that you know about it.

The fix is connecting your monitoring tool directly to your status page — so when an alert fires, a draft incident is already waiting for you.

The Flow

Here's what the integration looks like in practice:

Alert fires — your monitoring tool detects an issue (HTTP errors, timeout, failed health check).
Webhook sends — the monitoring tool sends a POST request to your status page's API.
Draft incident created — your status page creates an incident with the alert details. If AI is enabled, a customer-facing update is drafted automatically.
You review — open the incident in your dashboard, check the draft, edit if needed.
You publish — one click. The incident goes live, components update, subscribers get notified.

The key is step 4: the incident is a draft. It doesn't go live until you say so. This is important because not every monitoring alert deserves a public incident.

Why Drafts Matter

If every monitoring alert automatically became a public incident, your status page would be noisy and unreliable. Here's what you'd see:

False positives — a probe timeout that recovered in 10 seconds becomes a published incident that worries customers for no reason.
Flapping alerts — a service that's bouncing between up and down creates five incidents in an hour.
Internal-only issues — a staging environment goes down, or an admin tool has a bug. Neither affects customers, but both trigger alerts.

The draft step is the filter. Your monitoring tool captures everything. You decide what customers need to know.

Setting It Up

Most monitoring tools support custom webhooks — a URL they'll send a POST request to when an alert triggers. The setup is the same regardless of which tool you use:

1. Create an API key

In your status page dashboard, go to the API section and create a key. Give it a descriptive name (the name of your monitoring tool works). Copy the key — you'll only see it once.

2. Configure the webhook in your monitoring tool

Find the webhook or notification settings in your monitoring tool. You'll need:

URL: https://your-status-page-provider.com/api/v1/incidents
Method: POST
Headers:
- Authorization: Bearer YOUR_API_KEY
- Content-Type: application/json

3. Set up the request body

The body tells your status page what happened. At minimum, you need a title and your status page ID:

{
  "title": "API health check failing",
  "status_page_id": "your-page-id",
  "severity": "major"
}

For a smarter setup, include the raw alert data and let AI draft a customer-facing update:

{
  "title": "API health check failing",
  "status_page_id": "your-page-id",
  "severity": "major",
  "affected_component_ids": ["your-api-component-id"],
  "raw_input": "Monitor 'api-health' is DOWN. HTTP 503 on /api/health. Duration: 5 minutes.",
  "generate_ai_update": true
}

The raw_input is what the AI uses to write a customer-facing update. The more context you give it — error codes, duration, affected endpoints — the better the draft.

4. Test it

Trigger a test alert from your monitoring tool (most tools have a "send test notification" button). Check your status page dashboard — you should see a new draft incident waiting for review.

What to Include in the Webhook Payload

The basics:

Field	Purpose
`title`	Short description visible in the dashboard and on the status page
`status_page_id`	Which status page this incident belongs to
`severity`	minor, major, or critical — affects how the incident appears
`affected_component_ids`	Which components are affected (API, Dashboard, etc.)

For AI-assisted drafts:

Field	Purpose
`raw_input`	The alert text, error message, or description for AI to process
`generate_ai_update`	Set to `true` to auto-generate a customer-facing update
`tone`	professional, friendly, or minimal — controls the writing style

Tips for a Good Setup

Map monitors to components. If you have a monitor for your API health check, link it to your API component. If you have a monitor for your login page, link it to your Authentication component. This way, when an alert fires, the right component is automatically flagged.

Use severity thoughtfully. A health check timeout might be minor. A complete endpoint failure is major. A total outage is critical. Configure different severity levels for different alert conditions if your monitoring tool supports it.

Don't webhook everything. You probably have monitors for internal tools, staging environments, and third-party services. Only webhook the monitors that affect customer-facing services. Your status page should reflect what customers experience, not what your infrastructure is doing.

Include context in raw_input. "Monitor is DOWN" produces a generic AI draft. "HTTP 503 on /api/v2/users, connection pool exhausted, affecting all API requests for 8 minutes" produces a specific, useful draft that's close to publishable without editing.

The Result

With this setup, your incident response changes from:

Get alert → investigate → manually create incident → write update → publish → notify

To:

Get alert → draft incident already waiting → review → publish

The monitoring tool handles detection. The webhook handles creation. AI handles the first draft. You handle the judgment call: is this worth telling customers about, and is the wording right?

That's the workflow. Detection is automated. Communication is assisted. The publish decision stays human.

PageCalm helps small teams run status pages with AI-powered incident updates that sound human and ship fast. Try it free — no credit card required.

How to Connect Your Monitoring Tool to Your Status Page