Setup is only the beginning
A successful creation, coverage check or readiness check is not proof that a notification reached a person. MCP tools do not send test alerts. After setup, plan and run a controlled test from your application environment.
Agree on the test first
Write down:
- The expected failure or signal you will produce.
- The resource and incident you expect to observe.
- The intended recipient and notification route.
- The recovery action and how you will confirm it.
A test that sends alerts needs an explicit request. Choose a suitable time and let the affected people know through your normal team process.
Run and observe
Follow the relevant Monitor, Heartbeat or Webhook contract for the selected resource. Verify the incident and the delivery result in MonoDuty. Check the configured on-call response rather than assuming that a created resource has an appropriate recipient.
If the expected notification does not arrive, distinguish between the signal not reaching MonoDuty, an incident not appearing, and delivery not reaching the recipient. Record what you can actually observe. An unavailable observation or a tool error is unknown, not proof of success.
Confirm recovery
Restore the application or signal source and check the expected recovery state. An MCP action that resolves an incident changes incident state; it does not fix the underlying service.
If you need help, open a support request with the resource type, test time, expected outcome and sanitized observations. Keep credentials and secret URLs out of the report.
References
MonoDuty MCP setup and permissions · MonoDuty MCP overview
Reviewed against MonoDuty documentation on September 30, 2026.