How to Monitor Instatus with Vigilmon

Instatus is a modern status page platform that lets you communicate service uptime and incidents to customers. It provides customizable public status pages, scheduled maintenance announcements, subscriber notifications via email and SMS, webhooks, and integrations with monitoring tools like Datadog and PagerDuty. Instatus is what you reach for during incidents — but what happens when the incident communication tool itself is unavailable?

This guide covers how to monitor Instatus with Vigilmon so you know immediately if your status page or the Instatus API goes down, subscriber notifications fail, or the platform becomes unreachable exactly when your customers need incident updates.

Why Monitor Instatus?

Instatus is infrastructure for your customer communication. When it's down or degraded:

• Your status page goes offline — customers looking for incident updates see a broken page
• Subscriber notifications stop — email and SMS alerts to subscribers don't fire, leaving customers in the dark
• API calls fail — automated integrations that post incidents via the Instatus API (from PagerDuty, Datadog, or your own runbooks) fail silently
• Embedded status widgets break — if you embed an Instatus widget in your app or docs, it shows errors
• Scheduled maintenance pages don't publish — a failed maintenance announcement means customers are surprised by planned downtime

External monitoring from Vigilmon ensures you have visibility into Instatus availability independent of Instatus itself.

Key Metrics to Monitor

| Metric | Why it matters | |--------|---------------| | Status page availability | Customers must be able to reach the page during incidents | | Instatus API availability | Automated integrations depend on the REST API | | Subscriber notification delivery | Email/SMS alerts must fire during incidents | | Dashboard availability | Your team needs access to manage incidents | | Webhook delivery | Downstream tools depend on status change events |

Setting Up Vigilmon Monitors for Instatus

1. Your Public Status Page

This is the most critical monitor — it's what customers see during incidents:

1. Log in to Vigilmon → Monitors → New Monitor
2. Type: HTTP
3. Method: GET
4. URL: https://status.yourdomain.com (your Instatus status page)
5. Keyword check: your company name or All Systems Operational
6. Interval: 1 minute (status page availability is customer-facing)
7. Response timeout: 10 seconds
8. Save

Alternatively, if you use Instatus's default subdomain: https://yourcompany.instatus.com

2. Instatus API Health

The Instatus REST API is used by your automated integrations:

1. Type: HTTP
2. Method: GET
3. URL: https://api.instatus.com/v2 (base API endpoint)
4. Custom headers:
   • Authorization: Bearer your-instatus-api-key
5. Expected status: 200
6. Interval: 5 minutes
7. Save

3. Authenticated API Call — List Components

A lightweight authenticated probe confirms your integration credentials still work:

1. Type: HTTP
2. Method: GET
3. URL: https://api.instatus.com/v2/your-page-id/components
4. Custom headers:
   • Authorization: Bearer your-instatus-api-key
5. Keyword check: "name" (confirms the component list parsed correctly)
6. Interval: 5 minutes
7. Save

Create a dedicated Instatus API key for monitoring — label it "vigilmon-monitoring" in your Instatus dashboard so it's easy to rotate without disrupting production integrations.

4. Instatus Dashboard

Your team needs access to manage incidents:

1. Type: HTTP
2. Method: GET
3. URL: https://app.instatus.com
4. Keyword check: Instatus
5. Interval: 5 minutes
6. Save

Monitoring the Status Page Widget

If you embed an Instatus status widget in your app or documentation:

<!-- Typical Instatus embed -->
<script src="https://status.yourdomain.com/widget/script.js"></script>

Add a Vigilmon monitor for the widget script itself:

1. Type: HTTP
2. Method: GET
3. URL: https://status.yourdomain.com/widget/script.js
4. Expected status: 200
5. Keyword check: function (confirms valid JavaScript was returned)
6. Interval: 5 minutes

If the widget script becomes unavailable, your embedded status indicator goes blank or throws a console error — without this monitor, you won't know.

Automated Incident Posting via the Instatus API

Most teams automate incident creation via the Instatus API from PagerDuty, Datadog, or custom runbooks. Here's a probe that validates the full incident creation workflow:

# health/instatus_probe.py
import requests
import os

INSTATUS_API_KEY = os.environ["INSTATUS_API_KEY"]
PAGE_ID = os.environ["INSTATUS_PAGE_ID"]
COMPONENT_ID = os.environ["INSTATUS_COMPONENT_ID"]

def probe_instatus_incident_api() -> dict:
    """Create a draft incident and immediately delete it to verify API write access."""
    headers = {
        "Authorization": f"Bearer {INSTATUS_API_KEY}",
        "Content-Type": "application/json",
    }

    # Create a test incident
    create_resp = requests.post(
        f"https://api.instatus.com/v2/{PAGE_ID}/incidents",
        headers=headers,
        json={
            "name": "[MONITORING PROBE - DELETE ME]",
            "message": "Automated monitoring probe",
            "components": [{"id": COMPONENT_ID, "status": "OPERATIONAL"}],
            "status": "INVESTIGATING",
            "notify": False,
        },
        timeout=10,
    )

    if create_resp.status_code not in (200, 201):
        return {"ok": False, "error": f"Create failed: {create_resp.status_code}"}

    incident_id = create_resp.json().get("id")

    # Delete the test incident
    delete_resp = requests.delete(
        f"https://api.instatus.com/v2/{PAGE_ID}/incidents/{incident_id}",
        headers=headers,
        timeout=10,
    )

    return {
        "ok": delete_resp.status_code in (200, 204),
        "incident_id": incident_id,
    }

Wrap this in a health endpoint and monitor it with Vigilmon — if this probe fails, your automated incident posting workflow is broken.

Heartbeat Monitor for Notification Delivery

Subscriber notification delivery (email, SMS) is hard to test externally. Use a heartbeat approach with a test subscriber:

1. Create a test subscriber on your Instatus page (a monitoring-specific email alias)
2. When Instatus sends a test notification to that address, forward a ping to your Vigilmon heartbeat URL
3. Set the heartbeat timeout to match your expected notification frequency

This lets you detect notification delivery failures before a real incident exposes them.

Alerting Configuration

During an actual incident, Instatus becomes your primary customer communication tool. Alert thresholds should reflect that criticality:

| Monitor | Severity | Channel | |---------|----------|---------| | Status page availability | Critical | PagerDuty + Slack #incidents | | Instatus API | High | PagerDuty + Slack #incidents | | Dashboard availability | High | Slack #incidents | | Widget script | Medium | Slack #ops | | API write probe | High | Slack #incidents + email |

Response time thresholds:

• Warning: 2000ms (status pages need to be fast for customers under stress)
• Critical: 8000ms

Alert on first failure — don't wait for 2 consecutive failures on the status page monitor. When Instatus goes down during an incident, every second counts.

Creating a Fallback Communication Plan

Vigilmon monitoring tells you when Instatus is unavailable — but you also need a plan for what happens next. Consider:

1. Secondary status page — keep a simple static page on your own CDN that you can update manually
2. Social media template — prepare a Twitter/X post template for major incidents when the status page is down
3. Direct email list — maintain an emergency subscriber list outside Instatus for catastrophic failures

Document which Vigilmon alert triggers each fallback action.

Summary

| Monitor | URL | Check type | |---------|-----|------------| | Status page | https://status.yourdomain.com | HTTP GET, keyword | | Instatus API | https://api.instatus.com/v2 | HTTP GET, status code | | Components API | /v2/{pageId}/components | HTTP GET, keyword | | Dashboard | https://app.instatus.com | HTTP GET, keyword | | Widget script | /widget/script.js | HTTP GET, keyword | | API write probe | Your health endpoint | HTTP GET, keyword |

Key principles:

• Monitor your status page at 1-minute intervals — it's customer-facing and critical during incidents
• Test the API with authenticated calls, not just unauthenticated health pings
• Alert on first failure for the status page — don't buffer consecutive failures
• Have a documented fallback communication plan for when Instatus itself is the incident

With Vigilmon watching Instatus, you'll know within a minute if your incident communication platform is unavailable — so you can switch to backup channels before customers start asking what's happening.

Further Reading

• Monitoring StatusCake with Vigilmon
• Best Uptime Monitoring Tools for Developers 2026
• Monitoring Your REST API with Vigilmon