Metrics & alerts

Metrics

Metrics shows daily counters (UTC days) for today, yesterday, or the last 3, 7, 15, 30 or 90 days. Filter by domain. The main chart plots send volume. Use the event menu to plot delivered, opened, clicked, bounced, complained or unsubscribed counts instead. The two rate cards plot bounce rate (transient and permanent) and complaint rate. Each rate card draws a Risk line at the built-in threshold.

The platform bumps the counters as it sends messages and as delivery events arrive. The page is therefore cheap and always current.

Two built-in thresholds turn a number red: hard-bounce rate > 2 % and complaint rate > 0.1 %. The spam-rate ceiling of Gmail is 0.3 %; stay well under it. The domain page shows the same 30-day sent / hard-bounce summary.

By provider and bounce classification

Two tables sit under the charts. The first splits the range by mailbox provider (Gmail, Microsoft, Yahoo, Apple, Proton, other). It shows sent, delivered, hard-bounce and complaint rates, delayed deliveries and classified blocks. The second lists the Amazon SES bounce sub-types with counts. A problem at one provider shows here before it moves the totals. NoEmail and General mean dead addresses; MailboxFull is transient; ContentRejected points at the content.

Gmail spam rate

The worker pulls Gmail Postmaster Tools data once a day for every Verified domain that the service account can read. For each domain with data, the Metrics page shows a small Gmail spam rate chart. The chart draws the user-reported spam rate per published day and the 0.1 % line. Gmail publishes a day 1 to 3 days late, and only above a volume threshold. Days without data are gaps in the line. The domain page shows the latest day and the Gmail compliance status in the Gmail reputation card.

Alert rules

Admins manage the rules in Settings → Alerts. The worker evaluates the rules hourly. A rule fires at most once per UTC day.

Kind	Fires when
Hard-bounce rate	Hard bounces / sent over the last N days is above the threshold (%). Optional domain scope.
Complaint rate	Complaints / sent over the last N days is above the threshold (%). Optional domain scope.
DMARC failure rate	DMARC alignment over the last N days is below 100 − threshold % of reported messages.
Send queue backlog	Waiting jobs on the send queue exceed the threshold.
DNS drift	A Verified domain has any required record no longer OK (no threshold).
Gmail spam rate	The user-reported spam rate on the latest Gmail Postmaster day is above the threshold (%). Optional domain scope. The window does not apply.
Provider block	Classified provider blocks in the window (Microsoft S3140, Gmail 421-4.7.0, Yahoo TSS, DNSBL listings) exceed the threshold. The threshold is a count; 0 fires on the first block, and a rule without a threshold uses 2. Gmail codes count only when the reply names Google or the recipient uses Gmail. Optional domain scope. With Pause sending on, the rule opens a 4-hour provider hold. Mail to that provider waits, other providers send, and the org stays active. Admins release holds from the banner. A released hold stays released until the provider blocks again. See the runbook “Provider block”.

Each rule has a window (1–90 days), a channel and a target:

• Email — an address. The platform sends the alert from alerts@f5send.com through the normal send path (kind: alert).
• Slack — an incoming-webhook URL (https://hooks.slack.com/…). The platform stores it encrypted.

The hard-bounce, complaint, Gmail spam-rate and provider-block rules have an optional Domain field. With a domain, the rule reads the data of that domain instead of the organization total. The alert names the domain. Other kinds always cover the whole organization. If you delete the domain, the platform deletes its scoped rules.

For the Gmail spam-rate rule, set the threshold to 0.1 (percent). Google recommends that senders stay under 0.1 % and never reach 0.3 %. The rule reads the newest postmaster_stats row of each domain and ignores the window. Without Postmaster data, the rule stays silent.

Hard-bounce, complaint and provider-block rules have a Pause sending when this fires option. A hard-bounce or complaint rule pauses the organization and says so in the alert. A provider-block rule opens a 4-hour hold on that provider instead; the organization keeps sending to everyone else. The organization stays paused until an admin clicks Resume sending in Settings → Organization. The platform organization (alerts@) is never paused automatically. See Sending pause.

Every new organization starts with four rules, e-mailed to the person who created it:

• a hard-bounce rule (2 % over 1 day) with Pause sending when this fires on;
• a complaint rule (0.1 % over 1 day) with Pause sending when this fires on;
• a provider-block rule that opens a 4-hour hold on a provider after more than 2 classified blocks in a day;
• a delivery-silence rule that fires when mail leaves and nothing confirms it for a day. The rule counts only mail sent after its creation date. Old history does not trigger it.

Keep the pause on: a reputation incident must stop sending, not only send an e-mail. Bounce and complaint rules wait until the window holds at least 50 sent messages, so one bounce in two sends does not pause an organization. A DMARC failure rule waits for the same number of reported messages. Ops can change that floor with ALERT_RATE_MIN_SENT.

You can disable and re-enable rules without losing them. Delete removes a rule and its alert history after a confirmation.

Status page

/status is public. Anyone can open it without a session. The public half shows the worker and SMTP relay heartbeats, the transport state, the queues, a 90-day incident strip and the last 20 platform events. The page never shows organization names, reasons, delivery latency or infrastructure details.

The platform computes the badge at the top from the rows below it, never the other way round. Operational means four things. The worker heartbeat is fresh. The delivery provider accepts mail. No queue has failed jobs, and no job has waited longer than 15 minutes. Every other state shows Degraded.

The SMTP relay tile shows the relay heartbeat next to the worker. It does not change the badge yet; it joins the verdict when the relay goes live.

Sign in to see the tenant half on the same page. It lists the pauses and holds of your organizations and their delivery latency. It also lists their incidents of the last 7 days: pauses, holds, probe failures and transport failovers. The console rail stays on the left. The Status link in the rail opens this page.

GET /api/status

The same public snapshot as JSON. No API key. The platform answers 200 for both operational and degraded; the overall field carries the state. The response carries Cache-Control: public, max-age=30, and the platform caches the snapshot for 30 seconds. For a probe with 503 semantics use /api/health.

GET https://app.f5send.com/api/status

{
  "at": "2026-09-06T12:00:00.000Z",
  "overall": "operational",
  "worker": { "state": "alive" },
  "relay": { "state": "alive" },
  "transport": { "sendingEnabled": true },
  "queues": [{ "name": "send", "waiting": 3, "failed": 0, "oldestWaitingMs": 4000 }],
  "incidents": [{ "day": "2026-09-06", "autoPauses": 0, "providerHolds": 0, "probeFailures": 0, "failovers": 0 }],
  "recent": [{ "at": "2026-09-05T23:59:59.000Z", "kind": "provider_hold" }]
}

Field	Notes
at	When the platform took the snapshot (ISO 8601, UTC).
overall	operational or degraded, from the rows below.
worker.state	alive (heartbeat under 2 minutes old), stale (older) or none (no heartbeat).
relay.state	The SMTP relay heartbeat, same values and rule as worker.state. Not part of overall yet.
transport.sendingEnabled	true when the delivery provider accepts mail, false when it has paused the platform, null when the probe failed.
queues[]	One row per queue: name, waiting, failed, and oldestWaitingMs (age of the oldest waiting job, or null). -1 in a count means the probe of that queue failed.
incidents[]	One row per UTC day, oldest first, 90 rows. autoPauses, providerHolds, probeFailures and failovers are counts for that day.
recent[]	The last 20 platform events, newest first. kind is auto_pause, provider_hold, probe_failure or failover. No organization, no reason text.