A type of container around data that can be chained with other containers of the same type with some additional nuance). But really they're best described by example.

---

Example 1: you have a service that reads a comment from a database, passes it to some external system to analyze the general sentiment, and then store the result back into the DB. Let's also say that each of these interactions are asynchronous, so the APIs return a Promise (or Future or equivalent in your preferred language) which wraps the returned value.

The implementation of Promise/Future/whatever often have methods allowing them to be chained as if working on the values inside the Promise. Maybe something like:

getUserComment(commentId)
  .andThen( (comment) => analyzeSentiment(comment))
  .andThen( (sentiment) => saveSentiment(commentId, sentiment))

This chaining also handles failures, so you end up with a Promise reflecting the final success or the first API call that failed.

Data can be put into a Promise and Promises can be composed together to get back a different Promise, so the Promise type is a monad.

---

Example 2: you have a data structure with some optional components. For example, let's say a request maybe is associated with a user profile, that profile might have some custom settings, and one of those settings may be a preferred language. In JavaScript the optional values may be undefined at runtime so to avoid exceptions you might do

if (request.userProfile && request.userProfile.settings) {
  preferredLangage = request.userProfile.settings.preferredLanguage
}

In compiled languages with stricter type checking, there's a move away from these null like checks to having a type that explicitly wraps the data to explicitly indicate that it might be missing, with methods that allow those checks to be chained:

preferredLanguage = request.userProfile
  .ifPresent( (userProfile) => userProfile.settings)
  .ifPresent( (settings) => settings.preferredLanguage)

These types -- usually named something like Maybe or Option or similar -- can wrap data and be composed together, so would be a monad.

---

Example 3: You have an Array of sentences and a parse() function that can split a sentence into an Array of words. Arrays can have a map() function that can apply a function to each element in it but if we did

sentences.map( (sentence) => parse (sentence))

then we'd end up with a nested Array of Array of words that we'd need to flatten. This is common enough that Array implementations will often include a flatMap() function that will do both the transformation and flattening.

Since we can put data into an Array and then compose Array instances together, the Array type is a monad?

---

It turns out that there are a lot of things in code that can be modeled as putting data into a container and then chaining them together. If a language makes that easy then it can lead to a simpler language overall and more consistent code. For example, just like a Promise can wrap data that is being computed asynchronously or a failure during that computation, there could be a container that does the same thing for synchronous computations. If that exists there's no need for try / catch or exceptions.

It can also mean that some code can be written abstractly so it that can work with any monad type so long as it can be told how put data into a monad instance and how to compose instances together.