Available integrations
Alerts come in through one contract, updates go out to your channel
MonoDuty integrates in two directions: any HTTP-capable sender creates incidents through the universal Webhook, and every incident action is delivered outward to Slack, Discord, Microsoft Teams. Named inbound adapters remain out of the live catalogue until they pass their own end-to-end release gates.
No credit card required for the trial · EUR subscriptions through Stripe
01 / Directory
Available now
Only release-gated integrations appear in this directory. Named adapters move here after backend, UI, and delivery tests pass.
Universal HTTP Webhook
Send the documented MonoDuty JSON payload from any HTTP-capable system.
OutboundSlack
Deliver incident lifecycle updates to a channel as a Block Kit message with a deep link.
OutboundDiscord
Deliver incident lifecycle updates to a channel as a rich embed with status and severity.
OutboundMicrosoft Teams
Deliver incident lifecycle updates to a channel as an Adaptive Card.
02 / Overview
One inbound contract, three outbound destinations
Inbound, the release-gated MonoDuty directory lists Universal HTTP Webhook. A sender must POST the documented JSON shape to its service-specific mndty.com URL. The Webhook accepts a title or message plus optional severity, description, source, metadata, and deduplication key.
Outbound, incident lifecycle updates are delivered to Slack, Discord, Microsoft Teams with durable retries and per-attempt delivery evidence. Email, SMS, and voice remain the alerting channels that actually reach a person on call.
03 / Operating value
Keep each sender accountable
A useful connection has an owner, a documented payload, and a repeatable test.
Preserve source responsibility
The source keeps its detection role while MonoDuty handles incident ownership and response routing.
Use a stable schema
Require a title or message and send source context in the documented source and metadata fields.
Test retry behavior
Use an Idempotency-Key and verify both same-payload replay and conflict behavior before production.
04 / Workflow
Connect a source without inventing an adapter
Transform the sender payload into the documented native shape, then validate the complete response path.
- 01
Create an owned service source
Create the source under the correct team-owned service and copy its one-time Webhook URL securely.
- 02
Map the payload
Send title or message; map optional context into description, source, metadata, severity, and dedup_key.
- 03
Run a controlled alert
Confirm the first request, idempotent retry, conflicting retry, on-call ownership, and notification delivery.
05 / Plans
Choose the response capacity around the integration
Plan selection should reflect incident volume, team size, channels, and retention—not just the integration name.
Free
One user, 50 incidents/month, email, and 7-day retention.
Pro
Up to 25 users, 5,000 incidents/month, email/SMS/voice, escalation policies, and 30-day retention.
Business
Unlimited users and incidents, email/SMS/voice, escalation policies, and 90-day retention.
06 / Questions
Common questions
01Which inbound integration is generally available?
For senders creating incidents, the release-gated directory lists Universal HTTP Webhook.
02Are Slack, Discord, and Microsoft Teams live?
Yes, as outbound destinations on Pro and Business: MonoDuty delivers incident lifecycle updates to a webhook you create in the chat product. Acknowledging or resolving from inside the chat client is not part of the contract.
03Can any tool post its native payload unchanged?
No. The sender must produce the documented MonoDuty Webhook fields; named native adapters are not implied.
MonoDuty / Start
Connect one sender and test the complete route
Start with a representative payload mapping and verify validation, deduplication, ownership, delivery, and fallback before expanding.