Connect a source. Keep its scope.

Slack · signed Events API

1. Create a Slack app in your workspace. Configure bot scopes channels:history for public channels or groups:history for private channels. Subscribe to message.channels or message.groups, as appropriate. No message-writing scope is needed.
2. Create the Mitigly connection with the Slack workspace ID and one incident channel ID. Add the app’s signing secret in Add credentials.
3. Set Slack’s Event Subscriptions Request URL to the displayed endpoint. Mitigly verifies Slack’s signature and answers the URL challenge.
4. Install the app in Slack and invite it to the selected channel. In Mitigly, link the channel to a private incident.

Only new ordinary human messages from that workspace/channel are accepted. Messages from unlinked channels, bots, edits, deletions, and files are not collected. Historical messages are not imported. A channel can be linked to one incident at a time. All members of the Mitigly organization can read imported text; source channel membership is not inherited. Use a dedicated incident channel suitable for that audience.

Slack Events API · Signed request verification

PagerDuty · signed v3 webhooks

1. Create a Mitigly PagerDuty connection with the service ID. Save the draft to obtain its endpoint.
2. Create a PagerDuty v3 webhook subscription for that service and the incident events you need, using the endpoint.
3. Copy the signing secret returned by PagerDuty into Add credentials in Mitigly. If a delivery arrived before the secret was saved, retry that delivery in PagerDuty.

Incident events are authenticated and deduplicated by event ID. Events for the same PagerDuty incident ID share a Mitigly incident unless explicitly linked to another existing incident. Provider acknowledgement/resolution is recorded as context; it never automatically proves customer recovery or closes your Mitigly incident.

PagerDuty webhook setup · Signature protocol

AWS · CloudWatch metrics and EventBridge alarms

Configure a commercial AWS region, account ID, and Lambda function name. Add an identity with cloudwatch:GetMetricData only; an example permission statement is below. CloudWatch metric reads do not support resource-level IAM restriction through a function ARN, so use a dedicated account/identity where that breadth is acceptable. Mitigly restricts its own queries to the configured account/function. Temporary session credentials are supported and must be replaced before expiry.

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["cloudwatch:GetMetricData"],"Resource":"*"}]}

Optional alarms: configure the exact alarm name. Create an EventBridge API destination with POST, the Mitigly endpoint, and API-key authentication using X-Mitigly-Key and the webhook token shown after credentials are saved. Route only matching CloudWatch Alarm State Change events. Send the original event JSON without a transformer. Configure a dead-letter queue and retries in EventBridge. No forwarding script is required.

AWS alarm events use a stable alarm-name key. Link the alarm to the current incident when a new response episode starts. No automatic inference of alarm episodes is made.

Automatic impact uses Lambda Invocations and Errors, Sum, 5-minute buckets. It measures function invocation success, not unique customers, throttling, pre-invocation rejection, or full customer journey availability. Missing error buckets remain unknown rather than being assumed zero.

EventBridge API destinations · Lambda metric definitions

GCP · Cloud Run metrics and Monitoring alerts

Configure the exact project ID, region, and Cloud Run service name. Use a service account with read access to Cloud Monitoring, preferably a custom role limited to monitoring.timeSeries.list, or the broader predefined Monitoring Viewer role. Enter its email and PEM private key. The integration creates short-lived OAuth access tokens scoped to Monitoring read access.

Optional alert delivery: create a Cloud Monitoring webhook notification channel with basic authentication. Use username thelidhal and the webhook password shown by Mitigly. Select alert policies for the exact configured Cloud Run resource. The endpoint validates project, service, and region from the native alert payload. Error Reporting’s distinct schema is not supported.

Automatic impact sums run.googleapis.com/request_count across revisions and response codes for this resource. HTTP 5xx counts as failed. A successful measurement requires all requested time buckets and a complete response. Requests outside this resource, unique customers, and full journey coverage remain unknown.

Monitoring notification channels · Cloud Run request metrics

Azure · native App Service metric reads

Register an Entra application and grant its service principal Monitoring Reader at the specific App Service resource, or a custom role limited to Microsoft.Insights/metrics/read. Configure tenant ID, application client ID, and the complete /subscriptions/…/resourceGroups/…/providers/Microsoft.Web/sites/… resource ID. Add its client secret.

The integration reads Requests and Http5xx totals from Azure Monitor. It does not request write permissions or collect Action Group webhooks. The supported connection is a direct metric pull for Azure public cloud App Service, not every Azure resource or sovereign cloud.

Azure Monitor metrics API · App Service metric definitions

Start automatic measurements

After saving cloud credentials, choose Measure impact, select an active incident, and name the journey represented by the resource. The scheduler reads a 15-minute window every 15 minutes, ending at least 5 minutes behind real time to allow provider ingestion. Measure now performs the same read immediately. Provider API costs may apply.

Measurements attach automatically as evidence, appear in Impact, and feed the executive brief. Zero traffic, missing buckets, permission errors, pagination, and inconsistent counts produce unknown status. Measurements older than 30 minutes are labelled stale. These are scoped resource success rates, never a global SLA or unique customer count. Recovery remains a human decision supported by checks.

Credentials, delivery, and revocation

Credentials are encrypted with AES-256-GCM using an application key held in a Cloudflare Worker secret, bound to the organization, connection, and provider. Credentials are never returned by listing endpoints. Webhook credentials shown once must be stored in the provider’s secret configuration, never a query string. Replacing AWS/GCP credentials rotates their webhook token.

Signed Slack requests have a five-minute replay window. PagerDuty signatures authenticate the raw payload; event IDs prevent duplicate records. AWS and GCP use configured shared credentials over TLS. Revoke removes stored credentials, stops future collection, and marks automatic measurements unknown. It cannot retract requests already sent to a provider or remove the provider-side app, subscription, or key; revoke those in the provider as well. Previously imported evidence remains subject to your incident retention policy.

Provider URLs are fixed by the adapter, redirects are rejected, and responses are size/time bounded. A scheduled cycle processes a bounded number of due monitors, so an overloaded deployment can delay polling; freshness labels remain visible. No incident content is sent to an AI model or posted to Slack/PagerDuty.