Back to help
14

Dead link monitoring and health score

clk.ms can monitor destination health and warn the owner when a page becomes unavailable or suspicious. Checks cover not found pages, server errors, timeouts, expired SSL, domains that no longer resolve, and redirect loops. A redirect loop means the destination keeps forwarding the visitor in circles and never reaches a final page. The health score is a simple quality rating based on practical signals such as HTTPS availability, suspicious-domain status, redirect chain length, page response speed, and anti-phishing or safe-browsing results when those sources are available.

Destination health and Health Score

The link card can display the last check result, time, HTTP status, response latency, redirect chain, HTTPS, suspicious signs, and final status score. The checks are performed by the service in the background, so the information is relevant to the specified moment.

Statuses help differentiate between page unreachable, server error, timeout, DNS, TLS issue, or redirect loop. The absence of data does not mean that the site has been checked and is working correctly. Ratings do not guarantee content is secure or available in every country, network, or device.

Backup rules use supported problem statuses from a fairly recent record—no older than seven days. This is not an instant switch on every unavailability: the event must be detected by a check. After fixing the target URL, check the next update time and the actual result with a regular visit.

The diagnostic report separately reminds you if the check is missing, older than seven days, or refers to a different stored address. It does not perform a new network check on click.

Checking a link before publication

Open «My links» → link card → «Check before publishing». You need the right to view metrics and the availability of the corresponding tool for the owner and the user who opens it. The simulator and diagnostic report can be accessed independently of each other.

Routing simulator

The simulator shows which destination the current rules select for a given request. It uses the same selection algorithm as a real redirect, so you can check a campaign before sending visitors to it.

• Enter one country, one region and one language, for example DE, BE, de-DE. Empty fields represent a lack of information.

• Specify the User-Agent of the desired client. For example, for iPhone you can use Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Version/17.0 Mobile/15E148 Safari/604.1.

• Select a virtual visitor number from 1 to 254. Different numbers allow you to check the weight distribution; repeating the same number with the same User-Agent maintains technical identity in the simulator.

• If necessary, set UTC to 2000–2100. Empty time means the current moment.

• Click «Check route» and compare the selected address, recognized features and time with the expected ones.

• Change one attribute at a time and repeat: different language, device, country, time outside the interval, unknown attributes.

Simulation does not open the destination site, consume the click allowance, record a visit, scan or conversion, create a destination version, or send notifications. It checks destination selection. It does not test whether a visitor can pass password, OTP, referrer or other access restrictions.

Fallback routing uses saved destination health information. The simulator makes no network request and cannot predict a future outage. Selecting a future timestamp changes schedule evaluation and the age of the saved health result; it does not create a hypothetical health check.

For practice, create two rules for ru with the same priority and weights of 1:1, and keep the English page as the primary destination. Test ru with several virtual visitors, then test en and an empty language. Do not expect an exact 50/50 split from just a few samples.

Diagnostic report

The report evaluates the saved settings at the time it is generated. Refresh the page after making changes. Findings have the following severity levels:

Level — Meaning Blocks — There is a known reason preventing the normal transition now Warning — Setting or condition requires attention before posting Information — Feature that should be taken into account when checking

Checks cover the owner’s status, moderation, start time, expiry and click limit, expiry within 24 hours, ten or fewer remaining clicks, permanent HTTP redirects, destinations without HTTPS, additional access pages, referrer restrictions, incomplete UTM campaigns, missing current health checks, destination problems, expired rules, and a mixture of weighted and unweighted rules at the same priority.

For example, 301 is a reminder to consider caching, and a configured password is a reminder to test access. These findings do not necessarily indicate an error. A report with no findings only means that none of the listed known issues were detected in the saved data.

The JSON download creates clk-preflight-{code}.json. It contains schemaVersion, the short URL, checkedAtUtc, and a list of findings with stable codes and severity levels of blocked, warning and info. It does not include passwords or visitors’ personal data. Technical codes remain untranslated, so you can compare reports produced in different interface languages.

Save the report before an important publication, along with notes from a real test visit. Use it alongside a browser check of the destination and a test scan of the printed QR code.

Complete user guide ยท Practical course

How to apply this section

Each topic explains a feature, the user decision behind it, and how to use it without making the link harder to manage. Read the checklist before changing a link that is already shared.

Before you publish or update

  • Start from the visitor experience: who opens the link, from where, on which device, and what should happen next.
  • Check that the destination is correct, opens quickly, and shows the expected page for the intended audience.
  • Choose only the controls that match the goal, such as expiration, password, referrer, QR design, UTM, routing, or analytics sharing.
  • Save a short note for important changes so future review, rollback, or teamwork stays clear.
  • Open the short link in a private browser session and, when relevant, test mobile, desktop, QR scan, and protected access paths.
  • Review analytics after sharing to confirm real visitors, source quality, device mix, and campaign performance.

Practical example

Example: create a test link for an internal page, add a clear slug, set a short expiration, enable preview if the destination is sensitive, scan the QR code from a phone, then check whether the visit appears in the link statistics.

Next step

After this topic is clear, combine it with one adjacent feature. For example, pair UTM with campaigns, QR with print layouts, targeting with fallback, or webhooks with conversion tracking.