When a short link does not redirect

A request to a short link has two possible endings. It redirects, or it renders a page explaining why it did not. Which page appears is decided by a fixed sequence of checks, and the order is part of the contract rather than an implementation detail: more than one of these can be true about the same link at the same time, and the person holding it should be told the one that matters most.

The order the checks run in

Reading down, the first check that matches decides the answer.

An account suspension is checked first. It is a decision about the workspace as a whole rather than about this link, which makes it the broader fact, and it stops every link that workspace owns.

A blocked link comes next. Blocked means this destination was reported, reviewed, and taken down. A link that is both blocked and expired reports blocked, because "this was removed" is more useful to the person in front of it than "this ran out".

Those two are separate states rather than one, and the difference is what is actually true. Blocked says a destination was reviewed. For a link nobody ever reviewed individually, whose account was suspended over something else entirely, that sentence would be a lie told to a visitor.

Paused and expired follow, in that order. Both are the owner's own settings, and both outrank the flag below them, because a paused or expired link is not reachable at all right now, which is more relevant than the fact that somebody reported it.

A flagged link renders the interstitial, a page naming the destination host with a button to continue. Flagged means a person or a scanner saw something and was not certain, so it is deliberately a warning rather than a dead end. It is checked before the password gate so that a reported link warns even when it is also gated: the flag concerns the destination, the password concerns who may reach it.

A password protected link renders the unlock page. Anything past that point is live, and live is a redirect.

The four explained states answer 200, not an error status. A link that used to work and stopped is a real page telling a person what happened. Only a slug that was never a link at all is a genuine 404.

Unscanned is not the same as unsafe

A destination that has not been through the safety scan yet resolves live. Pending means unscanned, and treating it as a refusal would make the product unusable rather than safe: with no Safe Browsing key configured, every link is pending. Only a blocked status, set deliberately by a person or by a confirmed threat match, stops a redirect on its own.

Billing is never one of these states

None of the checks above is a billing check, and that is deliberate. A spent monthly allowance blocks the creation of new links and leaves every existing link redirecting. So does a downgrade, and so does a lapsed subscription. Through the API the same rule appears as a quota_exceeded response on link creation and nowhere else.

The two states that do stop a redirect on purpose, blocked and suspended, are abuse enforcement rather than billing. The guarantee is written that way round for a reason: a takedown has to be able to stop a redirect, and an unpaid invoice has to be unable to.

What the owner controls, and what the visitor sees

Three of the outcomes are settings on the link itself. Pausing a link stops it and can be undone. An expiry date stops it at a stated moment. A password puts an unlock page in front of it. Custom slugs, passwords and expiry dates are plan features, and the database enforces that rather than the interface, so an integration reaching the API directly meets the same limit as the dashboard does.

Editing the destination is not on that list, because it interrupts nothing. The new destination applies to the next request, and the link's own address never changes.

Blocked and suspended are not on the list either. Those are enforcement decisions, and a link owner cannot clear them.

Why a live link answers 302

A live link answers 302 with Cache-Control: no-store, never 301. A 301 is cached permanently by the browser, and permanently is the accurate word: an edited destination would never reach anyone who had followed the link once already, and a paused link would keep redirecting out of the visitor's own cache after it was paused. Neither failure produces a request that anyone here could see, and neither can be repaired from this side.

The click is recorded before that redirect is sent, rather than by a script on the destination page, so a click counts even when the destination never finishes loading. What is counted and what is filtered is written out on the methodology page.