MSAMM
Back to course

Oracle Integration Cloud: Building Integrations That Survive Production · Module 13 · Monitoring, tracking and alerting

Alerting: who, when, how loud

Lesson 132 of 175 · 3 min

Built-in notifications and their limits. ALERT FATIGUE AS A DESIGN FAILURE rather than a people problem. The platform can email on failure, and that is where most estates stop — every failure to one distribution list. It works for a month, and then the list has three hundred messages a week and nobody reads any of them. WHEN THAT HAPPENS THE INSTINCT IS TO BLAME THE PEOPLE, AND THAT IS WRONG. An operations team that ignores alerts has correctly learned that these alerts do not predict anything worth acting on. The alert stream was designed to be ignorable, and they adapted. Fixing the people does not work; fixing the stream does. THREE DESIGN DECISIONS DO MOST OF THE WORK. WHO: ROUTE BY WHO CAN ACT, WHICH IS LESSON 5 IN OPERATIONAL FORM. A credential failure goes to whoever fixes credentials. A rejected invoice goes to finance. An alert sent to…

The full lesson is part of the course

The video, the complete written lesson and the module quiz are included in Oracle Integration Cloud: Building Integrations That Survive Production, with a certificate on completion and a fourteen-day refund window.

See the course and enrol9 free lessons

Get the free lessons by email

We will email you a link to every free lesson in this course. No account needed, and one message only.

In this module: Module 13 · Monitoring, tracking and alerting

  1. 1The monitoring console
  2. 2Tracking variables: the one design decisionFree preview
  3. 3Reading a failed instance
  4. 4Payload retention, and its limits
  5. 5Errors versus rejections in the console
  6. 6Alerting: who, when, how loud
  7. 7The silent failure: nothing ran
  8. 8Reporting to the business
  9. 9What breaks: the integration nobody knew had stopped
  10. 10Lab briefing · Make a failure visible in five minutes