> ## Documentation Index > Fetch the complete documentation index at: https://docs.utmkit.co/llms.txt > Use this file to discover all available pages before exploring further. # Destination health > How UTMKit checks the page a link points at — before the link exists, and every day after — and how it tells you when a destination stops answering. A short link outlives the page it points at: the flyer is printed, the landing page is renamed, and every scan still resolves — onto a 404. UTMKit checks destinations before a link is created, and daily while it is live. ## Before a link exists Every destination is screened before it becomes a link, whichever door creates it — the assistant, the API, the MCP. Two things are refused: an address that is not public, and a destination a reputation service lists as malware, phishing or similar. A flagged destination never becomes a link, and nothing can switch the check off. If the safety check itself cannot answer, the link is not created and you are asked to try again in a few minutes. Destinations that already have links are re-checked daily, as many as each day allows. One that becomes listed later is withdrawn: its links stop resolving and the row on the Links page reads **Withdrawn**, followed by the reason. ## The daily check Once a day, UTMKit asks each destination that still has live links whether it answers. **Reachable** means a response with a status below 400; a redirect counts, and where it points is not followed. A 404, a 500, a timeout, a DNS failure, a refused connection or a TLS error marks the destination **unreachable**. Only ordinary web addresses on the standard ports are checked; withdrawn, expired and stopped links are skipped. The check gets through as many destinations as each day allows, oldest-checked first, so on a very large workspace not every destination is refreshed daily; one never checked shows nothing. The check never touches the link itself: a link to a dead page keeps redirecting, and you decide what to do. ## What you see On [Links](https://app.utmkit.co/links), a link whose destination failed its last check carries a red **Destination down** badge next to its edge badge — a link can be **Live** and point at a 404 at once. Hover for the reason and the day it started, for example `404 · since 2026-08-26`. The mark is set on the first failure and cleared on the first success. Editing the destination clears it immediately, and the new destination goes first in line. Type `destination:unreachable` in the search box to list only the failing links; the CSV export's `destination_status` column says what the badge says. The [activity log](/en/workspaces/activity-log) records one **Destination unreachable** entry per link when it stops answering and one **Destination recovered** when it answers again — never one per day. ## The Broken destinations page [Broken destinations](https://app.utmkit.co/broken-destinations) has two halves: **Failing right now**, the newest failures with a link to the rest, and the **weekly email** above it. Press **Set up the weekly email**, pick the weekday under **Send on** and list the recipients under **Send to**, one per line. Owners and admins can do this; a workspace has one such email, which can be paused, edited and deleted. The row shows the next send date and what happened last time. The mail is plain text, sent as UTMKit rather than under your brand. It lists the newest failures first — short link, destination, reason and start date — says how many more there are, links to the filtered list, and states in one sentence what the check covers and what it cannot see. Nothing is sent when nothing is broken, while the email is paused, when every address has opted out or bounced, or when the subscription has ended; the page says which. Every mail carries an unsubscribe link; an address that opts out, bounces or reports spam is struck through on the page and is never mailed again.