# Monitoring A test address checks one preview before a send. Monitoring checks every issue that actually goes out. Each newsletter you add gets its own SendScore address, and you subscribe that address to the newsletter the way any reader signs up. From then on, every issue that arrives is checked, compared with the issue before it, and kept in the newsletter's history. Monitoring is part of [the app](https://sendscore.ai/docs/self-hosting/#monitoring), which you run yourself. An account can monitor up to 5 newsletters by default, and you can change that. ## Add a newsletter Sign in to your app, open Newsletters, and add one. The form asks for these fields. | Field | What it sets | | --- | --- | | Name | What SendScore calls the newsletter, in the app and in alerts | | Days and time | When an issue normally goes out, such as Monday and Thursday at 09:00. Leave the days clear for a newsletter with no fixed schedule. | | Time zone | The time zone of that time, as an IANA name such as `America/Toronto` | | Grace period | How late an issue may be before it counts as missed, in minutes. It is 30 by default and at most 600. | | Alert email | Where alerts go. It is your sign-in address by default. Any other address must accept a confirmation link first, and alerts stay at the old address until it does. | | Pause alerts | Keeps receiving and checking issues but sends no alerts | The newsletter's page then shows its monitoring address, `m-@` the mail domain. The address never expires. ## Subscribe the address Sign the address up on the newsletter's own signup form, or add it as a subscriber in your newsletter platform. Many newsletters send a confirmation email first. It shows up on the newsletter's page as a signup message, and SendScore never follows confirmation or unsubscribe links, so open it with "View the message" and press its confirmation link yourself. That view shows the message as text with a list of its links, without its HTML or images. A message whose subject looks like a confirmation or a welcome email, with words such as "confirm", "verify", or "welcome", is kept as a signup message. It gets a report, but it is not compared with the issues and never causes an alert. ## What happens to each issue Every issue gets the same checks and [verdict](https://sendscore.ai/docs/verdict/) as a test address, with one addition. It is compared with the newsletter's previous issue, so the verdict's `changes` list what is different, such as a new DKIM signing domain, a new Return-Path domain, a new sending IP, a lost unsubscribe header, or HTML that grew past Gmail's clipping limit. A change that made a check worse also adds the `changes.regressions` warning, so it reaches `top_fixes`. The newsletter's page lists its last 100 messages, newest first, each with its verdict, whether it was ready to send, and how many changes it had. An issue that arrived after its grace period is marked late. ## Alerts SendScore emails the alert address when one of these happens. - **An issue is worse than the one before it.** A check fails that did not fail before, or a change made a check worse. A check that could not run does not count. The alert lists each of these and links to the report. - **An issue is missed.** With a schedule set, no issue reached the monitoring address by the end of the grace period after the expected time. The app waits 2 more minutes before it alerts, so an issue still being checked is not counted as missed. - **Two issues arrive for one send.** A second issue lands in the same scheduled slot as an earlier one, which can mean the issue went out twice. This one alert also says when the second issue is worse. Each event sends one alert, never repeated. A newsletter sends at most 10 alerts in a UTC day, and the app also caps alerts per account, per recipient, and per hour. Past any cap they are recorded but not sent. Alerts are kept for 35 days longer than the newsletter's issues. An alert that cannot be sent is retried after 1, 5, 15, and 60 minutes, then every 4 hours, for up to 24 hours. Every alert carries the same note as a verdict, that receipt at SendScore does not prove inbox placement at Gmail or any other provider. ## The heartbeat The heartbeat runs every minute and looks for missed issues. The schedule's time is local, so an issue due at 09:00 in `America/Toronto` stays due at 09:00 across the change to and from summer time. An issue counts for the scheduled slot it arrived nearest to, from halfway after the previous slot to halfway before the next one. A late issue still counts for its slot, so an issue that arrives after the missed-issue alert is shown as late on the newsletter's page. A deadline from before you set or changed the schedule is never reported, and neither is one more than a day old, so a restart after an outage does not send a burst of stale alerts. ## History Issues and their reports are kept for 365 days by default. Deleting a newsletter deletes its history too, and its monitoring address stops accepting mail. ## Limits A monitoring address accepts 50 messages a UTC day. Past that, the receiver answers `452`, so the platform tries again later, and the count starts over at midnight UTC. ## From the API and MCP `GET /api/v1/publications` lists your newsletters, and `GET /api/v1/publications/` returns one with its recent reports. See [the API](https://sendscore.ai/docs/api/#monitored-newsletters). The MCP connector adds a `list_publications` tool that returns the same list, so an agent can check how the last issue did. See [MCP setup](https://sendscore.ai/docs/mcp/#the-tools).