Mail & cache

Overview

Three monitor types that speak the protocol instead of just opening a socket. A TCP check on port 587 proves something is listening; an SMTP check proves the server greets you, accepts EHLO, negotiates TLS and — if you give it credentials — lets you authenticate.

Type	Schemes	Default port	What the check does
SMTP	smtp://, smtps://	587 (465 for smtps)	Banner, EHLO, STARTTLS, optional AUTH
IMAP	imap://, imaps://	143 (993 for imaps)	Greeting, CAPABILITY, STARTTLS, optional LOGIN
Redis	redis://, rediss://	6379	Optional AUTH, then PING → +PONG

The target can also be a bare host: mail.example.com, mail.example.com:993.

TLS

TLS takes three forms here, and confusing them is the first cause of “my server is fine but the monitor is red”:

Form	When	Behaviour
Implicit	smtps://, imaps://, rediss://, or port 465 / 993	TLS from the first byte
STARTTLS	SMTP and IMAP on any other port (587, 143…)	Plaintext connection, then upgraded
None	Redis without rediss://, or ?starttls=false	Everything in the clear

A “secure” port implies implicit TLS even without a scheme: mail.example.com:993 is IMAPS, not plaintext IMAP.

When STARTTLS applies and the server does not advertise it, the check fails and says so — rather than quietly continuing in the clear. An internal MTA that genuinely speaks plaintext is declared with smtp://mta.internal:25?starttls=false.

Credentials

The user and password are optional. Without them, the check verifies that the service answers its protocol. With them, it also verifies that authentication succeeds — which is what catches an expired mailbox password or a rotated Redis requirepass before your application does.

They live in the same encrypted columns as the database monitors: never in the URL, masked as *** in the API and every export, scrubbed from error messages. Credentials pasted into the URL (smtps://user:pass@mail.example.com) are moved out of it on save.

• SMTP — AUTH PLAIN when advertised, otherwise AUTH LOGIN.
• IMAP — LOGIN. A server advertising LOGINDISABLED is reported as such.
• Redis — AUTH <user> <password> (Redis 6+ ACL) when a user is set, otherwise AUTH <password> (the historical requirepass).

What counts as up

Type	Up	Down
SMTP	220 banner, EHLO accepted (250), and authentication accepted (235) when credentials are set	Connection refused, timeout, banner refused, STARTTLS missing or refused, authentication refused
IMAP	* OK greeting, CAPABILITY accepted, and LOGIN accepted when credentials are set	Same, plus LOGINDISABLED when credentials are set
Redis	PING answers +PONG	Connection refused, timeout, AUTH refused, -NOAUTH on PING

A server that closes the connection without a word after authentication is reported as a refusal, not as an empty response — the message says which step failed.

Latency is the whole dialogue: connect, TLS, and the protocol exchange.

Settings

Setting	Description	Default
Target	smtp.example.com:587, imaps://mail.example.com, redis://cache.example.com:6379	—
User / Password	Optional, stored encrypted	—
Port	Used only when the URL carries none	Type’s default
Skip TLS validation	Accept a self-signed certificate	off
Interval	Check frequency	plan-dependent
Timeout	Budget for the whole dialogue	10s

Notes

• A public SMTP or IMAP server that rate-limits connections may refuse a check that runs too often from several regions at once. Start at 5 minutes and one or two regions.
• Redis exposed on the public internet should require a password; a check without one that still succeeds is worth investigating on its own.
• The check never sends mail and never writes a key — the dialogue stops at QUIT / LOGOUT.