Three Limits and a Colour
Discord rejects an embed whose title runs one character over its limit. It does not trim it — it refuses the whole message. So the connector trims first, to a number deliberately below the documented one, and the margin between the two is the interesting part.
There are two ways to handle a provider's length limit. You can send whatever you have and let them deal with it, which works right up until the day a supplier with a long name and a purchase order with a long reference produce a title of two hundred and fifty-eight characters. Or you can trim before sending, which requires knowing the number — and choosing one that is not quite the number they published.
Refusal, not truncation
The important property is what happens on overflow, and it is worth being exact about it because it decides everything else.
Discord does not shorten an over-long field. It rejects the request. The entire message — title, detail, link, source line — does not appear, and what comes back is a validation error naming the field.
That is the correct behaviour for an API and the worst possible behaviour for a notification. A truncated alert still tells somebody an approval is waiting. A rejected one tells nobody anything, and it fails precisely on the records with the most going on — the long supplier name, the reference with a project code in it, the order with a note attached.
The messages that overflow are the messages about the complicated records, which are the ones somebody most needs to see.
Three fields, three caps
So each of the three text fields is trimmed on the way in, with an ellipsis marking the cut.
| Field | What it carries | Roughly |
|---|---|---|
| Title | The one line that has to work alone | A long sentence |
| Description | The detail underneath it | Several paragraphs |
| Footer | The small source line at the bottom | A couple of sentences |
Every one of those is generous relative to what an operational alert actually contains. The description cap alone is longer than most of the notifications this system sends put together. They exist for the outlier, and the outlier is what a limit is for.
Why the numbers are not the published numbers
Here is the detail worth the post. Each cap used is a little below the one Discord documents — a handful of characters on the title, a couple of hundred on the description.
That margin is not caution for its own sake. It exists because the number of characters in a string is not a single well-defined quantity, and the two parties can count differently.
-
An emoji is not one character
Depending on how you count, a single emoji is one thing, two, or four. A flag or a family emoji is several code points joined together, and a limit measured in one unit is not a limit measured in another.
-
An accent may be one character or two
The same visible letter can be a single code point or a letter followed by a combining mark. Both are correct, both are common in real data, and they count differently.
-
The ellipsis has a length too
Trimming to exactly the limit and then adding a marker produces a string one longer than the limit, which is the most embarrassing way to fail a length check.
-
A limit can be silently tightened
A provider that reduces a documented maximum affects everybody sitting exactly on it and nobody sitting under it. The margin is what makes that somebody else's incident.
The cost of the margin is a few characters of detail on the longest notifications anybody sends. The cost of not having it is a rejected message on an unpredictable subset of records. That trade is not close, and it is the general shape of every good limit decision: give up something you can measure to avoid a failure you cannot predict.
The colour is a number
A small, genuinely surprising thing. The coloured bar down the left edge of a Discord embed is set as a decimal integer rather than as a colour string.
So a brand colour written the way every designer, stylesheet and design tool writes it has to be converted into a large plain number before it means anything to Discord. Send the familiar string and the field is invalid.
It is stored converted, once, with the original written beside it in a comment — because a large decimal number in isolation is unreadable, unsearchable and impossible to check against a brand guide. Six months later, nobody can tell whether it is right without doing arithmetic.
That is a tiny instance of a habit worth having generally: when a value has to be stored in a form people cannot read, keep the readable form next to it. The comment is not documentation, it is the only version anybody can verify.
And the title is the link
One structural difference from the other chat destinations. Slack and Teams put the link on a button underneath the message. A Discord embed has no button — instead, giving the embed an address makes its title clickable.
The practical result is the same and the visual result is not, which is the honest description. The reader gets one obvious way through to the record; it is the headline rather than a separate control.
It also means the link is always attached to the part of the message that survives everything — the title is what shows in a notification, in a preview, and in the message list. The one element that cannot be missed is the one carrying the way through.
What is in place, layer by layer
The Discord connector as it stands
Every text field trimmed before sending
Title, detail and source line are each capped with an ellipsis, so a long record produces a shortened notification rather than a rejected one.
Caps set below the documented maxima
A deliberate margin, because character counting differs between the two parties on emoji and accented text and a limit can be tightened without notice.
A rich embed rather than plain text
A coloured bar, a heading, the detail and a subtle source line, so a channel carrying several a day stays scannable.
The brand colour stored as the provider wants it
Converted to the numeric form Discord requires, with the readable form recorded beside it so it can be checked against a brand guide.
A clickable title where there is a destination
The embed carries the link on its heading, which is the element that survives every preview and notification.
Optional parts genuinely omitted
No detail means no description; no link means an ordinary title. A short notification arrives short rather than padded.
No escaping, deliberately
Embed fields are structured values rather than markup, so an ampersand in a supplier name is passed through as itself.
A bounded wait
A twelve-second ceiling, so a slow response cannot hold up the work that raised the notification.
The provider's rejection surfaced
A refused message reports Discord's own status and body, which names the offending field rather than reporting a generic failure.
A successful Discord send returns no content at all — the status is the entire answer, which is why success here is judged on the status rather than on anything in the body.
Three positions held on purpose
- Trimming happens on our side rather than being left to the provider. A shortened alert still does its job; a rejected one reaches nobody, and it fails on exactly the records that were most worth a notification.
- The caps sit below the published limits. The few characters given up are measurable and small; the failure avoided is unpredictable and total, and that is not a close trade.
- A value stored in a form people cannot read keeps its readable form beside it. A large decimal integer is unverifiable six months later, and the comment is the only version anyone can check against a brand guide.
Five questions about provider limits
What happens to an over-long message?
A good answer sounds like
Trimmed, not refused.
What ours actually is
Each field is capped with an ellipsis before sending, so a long record still produces a notification.
Are the caps the documented ones?
A good answer sounds like
Slightly under, on purpose.
What ours actually is
A deliberate margin, because the two sides can count characters differently and a maximum can be tightened.
Does an emoji in a supplier name break it?
A good answer sounds like
No.
What ours actually is
The margin exists for exactly that case, where one visible symbol counts as several units.
How is the brand colour handled?
A good answer sounds like
Converted, and recorded.
What ours actually is
Stored in the numeric form the provider requires, with the readable form kept beside it.
Can the reader reach the record?
A good answer sounds like
Yes.
What ours actually is
The embed's heading is the link, which is the element that survives every preview.
Our take
Length limits are the most boring thing an integration has to handle and one of the few that fail on real data rather than on test data. Test data has short names. Production has a supplier whose registered name runs to nine words, a project code stapled to a purchase order reference, and somebody who put an emoji in a note because it was faster than typing urgent. Sitting a comfortable distance under a published limit costs a handful of characters on the longest message you will ever send, and it removes an entire category of failure that would otherwise arrive without warning on the busiest week of your year.
Alerts for teams that live in Discord
Approvals, exceptions and deadlines as native embeds, trimmed to arrive rather than sized to be refused.
Talk through operational alertsFrequently asked questions
Will a long notification be cut off?
Only if it is genuinely enormous — the detail cap alone is longer than most operational alerts put together. Where a message does run over, the title survives intact and the detail is trimmed with an ellipsis, so the notification still says what happened.
Why does the Discord message have no button?
A Discord embed does not offer one. Giving the embed an address makes its heading clickable instead, which reaches the same record with one click and attaches the link to the element that shows in every preview.
Can we change the colour of the bar?
It is a fixed value rather than a per-workspace setting, chosen so alerts from this system are recognisable at a glance in a channel that carries several sources. Discord takes it as a numeric value, which is worth knowing if you are ever comparing it against a brand guide.
What does a successful send look like?
A response with no content at all — Discord answers with a status and an empty body. That is why success here is judged on the status alone, unlike one of the other chat connectors whose provider can answer healthily and still decline.
Do emoji in our data cause problems?
No, and they are the reason the caps sit below the documented limits. A single visible emoji can count as several units depending on how it is measured, so a message sitting exactly on a limit could be over it by the provider's count. The margin absorbs that.
