Integrations
Openstatus
Overview
This document provides a detailed guide to integrating OpenStatus with Callgoose SQIBS for real-time incident management. The integration uses OpenStatus webhook notifications to send monitor state changes (failures and recoveries) to Callgoose. Callgoose API Filters then convert those webhook payloads into incidents that are created and auto-resolved based on monitor identity and status.
Prerequisites
- A Callgoose SQIBS account with permissions to create API Filters and access the integration endpoint.
- An OpenStatus account (self-hosted or cloud) with admin access to Monitors and Notification settings.
- A valid Callgoose API token and the Callgoose API endpoint.
- A test OpenStatus monitor (recommended) to validate webhook delivery.
1. Prepare Callgoose: Obtain Endpoint and Token
1.1 Generate or locate a Callgoose API Token
Create or obtain an API token in Callgoose that has permissions to create incidents via the process endpoint. Store the token securely.
1.2 Construct the Callgoose process endpoint
You will use the Callgoose process API endpoint as the webhook target in OpenStatus.
- Format: https://****.callgoose.com/api/v1/process?token=<YOUR_TOKEN>
- Note: If your Callgoose instance requires the token in a Header rather than the URL, ensure you note that for Step 2.
2. Configure OpenStatus Webhook
OpenStatus supports webhook notifications for monitor state changes. You must configure a webhook destination that posts JSON to Callgoose.
2.1 Where to add the webhook
Navigate to Settings → Notification Channels (or Integrations depending on your version) → Add Notification Channel → Select Webhook.
2.2 Webhook settings
- Name: Callgoose SQIBS Integration
- Method: POST
- URL: Input the Callgoose process endpoint from Step 1.2.
- Events: Ensure you subscribe to both Monitor Fails and Monitor Recovers (or equivalent "Up" and "Down" events). This is critical for auto-resolution.
2.3 Save and Test
Save the configuration. Most OpenStatus versions provide a "Test" button next to the notification channel. Click it to send a sample payload to Callgoose.
3. Verify Payload and Inspect Keys
OpenStatus webhook payloads can vary depending on the version (Cloud vs. Self-Hosted) and configuration. You must identify the exact JSON keys Callgoose receives before creating filters.
- Trigger a Test: Use the "Test" button in OpenStatus, or manually toggle a test monitor to "Down" and then "Up".
- Check Callgoose Logs: Go to Callgoose SQIBS → Settings → Logs (or Inbound Traffic).
- Copy the JSON: Find the request from OpenStatus and copy the Body/Payload.
- Identify Key Fields: Look for the specific keys representing:
- Monitor ID: (Common keys: id, monitor_id, monitorId)
- Status/State: (Common keys: status, state, type)
- Values: (e.g., does it send "down" or "DOWN"? "up" or "RESOLVED"?)
4. Reference: Example OpenStatus Payloads
Use these examples for reference only. Always use your actual logs from Step 3.
4.1 Failure / Trigger Payload Example:
{
"id": "mon-12345",
"name": "payments-service",
"status": "down",
"response_time": 1200,
"timestamp": "2025-11-01T12:05:00Z",
"message": "Monitor returned 504 from probe in eu-west-1"
}
4.2 Recovery / Resolved Payload Example:
{
"id": "mon-12345",
"name": "payments-service",
"status": "up",
"response_time": 140,
"timestamp": "2025-11-01T12:12:30Z",
"message": "Monitor returned 200 from probe in eu-west-1"
}
5. Create API Filters in Callgoose SQIBS
Use the JSON keys identified in Step 3 to create your filters.
5.1 Trigger Filter — Create Incident
This filter creates an incident when a monitor fails.
- Payload JSON Key: "status" (or your identified state key)
- Key Value Contains: [down, failed, critical] (add all variations observed in logs)
- Map Incident With: "id"
- Incident Title: "name"
- Incident Description: "message" (or leave empty to store the full JSON).
5.2 Resolve Filter — Auto-Resolve Incident
This filter closes the incident when the monitor recovers.
- Payload JSON Key: "status" (or your identified state key)
- Key Value Contains: [up, ok, resolved, recovered]
- Incident Mapped With: "id"
- Important: The "Map Incident With" key must match the key used in the Trigger Filter exactly.
6. Test the Integration
6.1 Trigger Test
Perform a trigger test to confirm that Callgoose correctly creates an incident when OpenStatus reports a failure.
- In OpenStatus, temporarily configure a monitor to return a failing state (for example, pointing it to a non-responsive endpoint or disabling the target service briefly).
- Ensure the monitor status changes to down, and OpenStatus sends the failure webhook.
- In Callgoose, verify that an incident is created using the mapped key (such as monitor_id) and that the title and description match the payload fields from the Trigger Filter.
- Confirm that the incident appears in the Callgoose incident dashboard with the correct severity and timestamp.
6.2 Resolve Test
Perform a resolve test to confirm that Callgoose automatically resolves the incident when OpenStatus sends a recovery event.
- Restore the monitored endpoint or re-enable the service so that OpenStatus detects it as healthy.
- Ensure the monitor status changes to up, and OpenStatus sends the recovery webhook.
- In Callgoose, verify that the previously created incident mapped with the same monitor_id transitions to Resolved.
- Confirm that the resolved time matches the recovery event received from OpenStatus.
7. Troubleshooting
- Incoming payload not received
- Check OpenStatus webhook delivery logs (if available) for 4xx or 5xx errors.
- Verify the endpoint URL and token are correct.
- Ensure no firewall rules block OpenStatus IPs from reaching Callgoose.
- Incidents not auto-resolving
- Case Sensitivity: Check if OpenStatus sends "UP" (uppercase) but your filter expects "up" (lowercase).
- Mapping Mismatch: Ensure the Trigger and Resolve filters both use the exact same unique ID field (e.g., id). If the Trigger uses name and Resolve uses id, they will not link.
- Missing Events: Verify in OpenStatus settings that "Recovery" or "Up" notifications are enabled for the webhook.
- Wrong or missing payload fields
- If the Incident Title appears as {{name}} (literal text), it means the key name does not exist in the JSON payload. Re-check the logs in Step 3 and update the filter variable to match the correct key (e.g., monitor_name).
8. Conclusion
Integrating OpenStatus with Callgoose SQIBS bridges synthetic monitoring with incident management. By configuring OpenStatus webhooks and validating the payload structure via Callgoose logs before configuring filters, you ensure reliable, automated incident tracking and resolution.
For additional reference:
