Testing and troubleshooting - Mattermost

2 min read Updated: 11.09.2026

The test message

A Send test button sits next to every event type. It posts a sample message with the project name, the event type and the detection time - down the same path as a real alert. The test needs a saved or just-entered webhook address and a chosen channel. Missing either ends in a message about an incomplete configuration before DockRay even tries to send the request.

Common problems

DockRay rejects the address on save

The address must be public HTTPS, with no username or password embedded in it, and the hostname must resolve to a public IP address. An HTTP address, an internal one (say, a Mattermost server behind a private IP with no public proxy), or a typo in the domain all end in the same message - it is one shared rule for every field of this kind in the panel, not a validation specific to Mattermost.

The test passes, but real alerts never arrive

Check the routing for that specific event type - it may be set to 'don't send', or the project may have explicitly overridden the account's inheritance with only a channel, without turning delivery on. It is also worth checking whether the event actually happened: issue only fires on the first occurrence of a new error.

The webhook used to work and has since gone quiet

Someone may have deleted the webhook on the Mattermost side - for example while cleaning up server integrations, or after a change of channel admin. DockRay has no way to find out on its own: a deleted webhook simply stops responding. Create a new one and paste it in place of the old.

The message lands in a different channel than expected

Mattermost lets a webhook post to a channel other than the one it was created for, if DockRay gives the channel explicitly in the request. If the channel field in routing is blank, the message goes to the webhook's default channel - the one it was created for, not the one that seemed 'obvious' from the integration's name.

A sudden error spike doesn't send a notification

The error-spike criterion needs a minimum number of events in the time window and a sufficient multiple of that project's normal traffic at the same time, and this alert type is sent for the same project at most once every few hours - a second wave in a short interval is muted on purpose.

Still not working

Work through the troubleshooting checklist, and if that does not help, write to us. Include the project name, the integration version and roughly when you ran the test: it shortens the way to an answer.

Chat with us The chat is closed right now Available: Mo–Fr 08:00–18:00