Send only the evidence you need.

1. Create a scoped connector

A verified organization owner or administrator creates a connector under Workspace → Data settings. Set the service and region. Save the token in your forwarding system’s secret manager. The token is shown once and stored only as a hash by Mitigly.

2. Forward selected events

POST JSON to the displayed endpoint with an Authorization: Bearer header. Use a stable eventId for retries and the same incidentKey to attach related observations to one incident. Keep keys unique within this connector. Separate connectors do not automatically correlate incidents.

{
  "eventId": "checkout-alert-123",
  "incidentKey": "checkout-2026-09-21",
  "incidentTitle": "Checkout errors in us-east-1",
  "source": "alert",
  "title": "Checkout error rate exceeded threshold",
  "body": "Measured 12 failures among 400 requests; customer count unknown.",
  "url": "https://your-monitoring.example/alerts/123",
  "observedAt": "2026-09-21T10:00:00Z"
}

Sources: alert, logs, slack, jira, human. A source label identifies your forwarded event; it does not establish a native provider connection. No external URLs are fetched. Redact secrets and personal data before sending.

3. Handle delivery

202 means durably accepted. A repeated eventId returns 200 with duplicate:true and the original incident ID. Fix 400 errors before retrying. Retry 429 and 5xx with exponential backoff and the same eventId; stop on 401 and check credentials. Limit: 120 requests per minute per connector, 64 KiB per request. The source must retain and retry undelivered events. Changed content with an existing eventId is not applied; send a new eventId for corrections.

Last receipt and rejection status appear under Workspace → Data settings. A successful receipt does not prove the upstream source is complete or healthy. New source evidence invalidates approved briefs and recorded recovery verification.

4. Revoke and remove

Administrators can revoke a connector immediately. Existing incident records remain available until deleted. Incident exports include evidence, decisions, revision history, and audit entries. Explicit incident deletion removes these and their deduplication records; resend of an old event after deletion can recreate the incident unless its connector is revoked.

Data handling

All active members of the organization can read its incident records. Viewers cannot modify them. Responders can record evidence and decisions; only owners and administrators manage connectors, retention, and deletion. Evidence inherits organization-level access; channel-level source permissions are not imported. Forward only material appropriate for everyone in the organization.

Records are stored in Cloudflare D1. This workflow does not send data to an AI model. Source links are stored, not fetched. Retention is off by default; administrators may opt into deleting resolved incidents after 30–3650 days without updates. The scheduled cleanup runs every 15 minutes in bounded batches. Application deletion does not promise immediate erasure from provider recovery backups; provider backup expiry remains separate. Production backup/restore validation and a contractual retention policy are required before making enterprise recovery or erasure commitments.

Impact values and passing checks are supplied by people or their selected source records. Mitigly validates scope, counts, timestamps, and required references; it does not independently measure infrastructure health. Recovery requires fresh checks for every recorded journey and scope. No infrastructure changes, ticket writes, or messages are sent by this release.