Service Status

This page describes what is monitored around the clock and how you are notified.

What is monitored

The application

The health check queries the database, not just the homepage: a site that displays but can no longer read its data is down, even if it responds.

The send engine

The service that drains the queue runs separately from the application: sending fifty thousand messages does not depend on a web page. If it stops, messages stay in queue and resume on restart.

Scheduled campaigns

Checked every minute. A campaign that cannot go out reverts to draft and its owner receives a message explaining why. Beyond three hours of delay, it is not sent as a catch-up.

Stuck messages

A message locked by an interrupted send is re-queued every two minutes, without waiting for a restart.

If the sending server fails mid-run, nothing is lost — the next one resumes where it stopped.CAMPAIGN QUEUE1,200senthereinterrupted440waitingThe next server resumes from the midpoint — no duplicates.
If the sending server fails mid-run, nothing is lost — the next one resumes where it stopped.

One workspace can't damage the others

The sending infrastructure is shared: a workspace importing a purchased list would put everyone else's reputation at risk. This is the one place where Mailcheer refuses instead of warning.

  • Before preparing a campaign, the last thirty days of the workspace are reviewed. Above 5% bounces or 0.1% complaints, sending is refused — not just flagged.
  • A rate means nothing without volume: bounces are only measured from 50 sends, complaints from 1,000. One person marking you as spam does not block you.
  • During sending, if a quarter of the first messages come back as errors, the campaign stops on its own: messages still in queue are dropped rather than sent.
  • The suspension applies to the offending workspace, never to the others.
If bounces spike during a send, the campaign stops itself and returns to draft.Sent1,200Bouncesabove 25%In queueabandonedThe campaign returns to draft — the list gets corrected.
If bounces spike during a send, the campaign stops itself and returns to draft.

How you are notified

One thing is written to you, and it is the one that matters: a scheduled send that did not go out. The workspace owner receives an email naming the campaign, the planned time and the exact reason. You schedule precisely so you no longer have to watch. A failure that only lives in a screen no one has reason to open does not exist.

Account emails have a second path. They normally go through our sending provider; if it refuses — outage, quota, suspension — your sign-in code goes through a different route, with a different provider. A product whose front door depends on a single vendor has no door. Campaigns never take this second path: it is the sending provider that tracks opens, bounces and reputation.

Something wrong right now?

Write to us with the workspace concerned and what you are seeing.