Uptime and incident response for a redirect service

The blast radius is unusually wide

A redirect layer is a single dependency shared by everything you have ever published. When it fails, it does not degrade one campaign; it breaks the email sent this morning, the code on last year's packaging, the link in your documentation and the QR sticker in a shop window, simultaneously. Very few components in a marketing stack have that property.

This is the argument for treating it as production infrastructure rather than as a marketing tool. The people who own it should be the people who carry a pager, and its monitoring should look like the monitoring for a service that customers depend on, because it is one.

Monitor the redirect, not the dashboard

A health check that confirms the web application is reachable tells you almost nothing about whether links work. The thing to check is a real short link: request it, assert the status code, assert the exact destination in the Location header, and assert the response time.

Use a link created specifically for monitoring, pointing at a stable destination, and never edit it. Check it from several regions, because a redirect layer distributed across edge locations can fail in one region while looking healthy from your office.

Latency is a failure mode long before errors are

Redirects are supposed to be fast, and a slow redirect is invisible in an error rate. If the median climbs from tens of milliseconds to several hundred, every campaign gets worse and nothing alerts. People simply abandon slightly more often, which appears as a soft decline in conversion that nobody attributes to infrastructure.

Alert on percentiles, not on averages, and set the threshold at a level that would be noticeable to a person on a phone rather than at the level where the service is obviously broken. The high percentiles are where the real experience lives, and an average happily conceals a badly degraded tail.

Know which failure you are having

Redirect outages come in a few recognisable shapes and the response differs sharply between them. DNS not resolving is a registrar or nameserver problem and your service is fine. A certificate expiry produces a browser warning rather than an error page and looks fine to a command line client that skips verification. The service returning errors is an application problem. A single wrong destination is a data problem affecting one link.

The first action in any incident is to establish which of these it is, because the fixes share nothing. Have a short runbook that names the four and gives the one command that distinguishes them.

Certificate expiry is the most common self-inflicted outage

Automated renewal fails quietly more often than people expect: a validation record that was changed, a rate limit hit during testing, a domain moved to a new provider without the renewal following it. Nothing is wrong until the day the certificate expires, at which point every link on the domain shows a security warning.

Monitor days remaining on the certificate as an explicit metric with an alert well before expiry, and check it for every domain including the ones nobody has thought about in a year. Those are precisely the ones where renewal has silently stopped.

Serve something rather than nothing when the data layer is down

If the lookup that resolves a slug to a destination is unavailable, the service does not have to fail closed. A cached mapping for popular links, or a last-known-good copy held at the edge, keeps the most important traffic flowing through a database incident. For links not in the cache, a branded page explaining that something is temporarily wrong is better than a raw server error.

Decide this behaviour in advance and test it by taking the dependency away deliberately in a non-production environment. Discovering during an incident that your fallback path was never exercised is a common and avoidable second failure.

Have a communication path that does not depend on the domain

If the short domain is down, you cannot use it to tell anyone. Status pages, support replies and social posts must all point somewhere else. This sounds obvious and is routinely forgotten, because the short domain is what everyone in the organisation has learned to paste.

Prepare the wording in advance for the two audiences that matter: internal teams who will ask whether to pause a send, and external users who followed a link and got an error. Both need a sentence they can act on rather than an assurance that you are investigating.

Review afterwards and fix the detection first

Most redirect incidents are short and the fix is quick once the cause is known. The expensive part is the interval before anyone noticed, which is frequently longer than the outage itself. A review that concentrates on how the failure was detected, and by whom, will usually produce more value than one that concentrates on the root cause.

Turn each review into one concrete monitoring change. Over a year that accumulates into a service where failures are noticed by a check rather than by a colleague asking whether a link is broken, which is the actual goal.