Skip to main content
Cutt.ly logo

Is Cutt.ly Down?

No — Cutt.ly is up

Reachable from all 8 checked regions

Average response time: 898ms

Last checked · checks run every 6 hours

Official status page: https://status.cutt.ly

Cutt.ly uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
763ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 32 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

32-day clean streak
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 32 checks
Sep 16: 100.00% uptime, 23 checks
Sep 17: 100.00% uptime, 31 checks
Sep 18: 100.00% uptime, 31 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 32 checks
Sep 21: 100.00% uptime, 32 checks
Sep 22: 100.00% uptime, 32 checks
Sep 23: 100.00% uptime, 32 checks
Sep 24: 100.00% uptime, 32 checks
Sep 25: 100.00% uptime, 32 checks
Sep 26: 100.00% uptime, 32 checks
Sep 27: 100.00% uptime, 32 checks
Sep 28: 100.00% uptime, 32 checks
Sep 29: 100.00% uptime, 32 checks
Sep 30: 100.00% uptime, 42 checks
Oct 1: 100.00% uptime, 29 checks
Oct 2: 100.00% uptime, 32 checks
Oct 3: 100.00% uptime, 32 checks
Oct 4: 100.00% uptime, 32 checks
Oct 5: 100.00% uptime, 32 checks
Oct 6: 100.00% uptime, 32 checks
Oct 7: 100.00% uptime, 32 checks
Oct 8: 100.00% uptime, 32 checks
Oct 9: 100.00% uptime, 32 checks
Oct 10: 100.00% uptime, 32 checks
Oct 11: 100.00% uptime, 32 checks
Oct 12: 100.00% uptime, 32 checks
Oct 13: 100.00% uptime, 32 checks
Sep 14 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

jnb
1292ms
DNS 254ms TCP 0ms TLS 3ms TTFB 888ms
lax
660ms
DNS 181ms TCP 60ms TLS 64ms TTFB 511ms
lhr
217ms
DNS 94ms TCP 2ms TLS 10ms TTFB 192ms
nrt
1077ms
DNS 296ms TCP 1ms TLS 7ms TTFB 580ms
ord
708ms
DNS 290ms TCP 1ms TLS 11ms TTFB 467ms
sin
1320ms
DNS 379ms TCP 2ms TLS 8ms TTFB 958ms
sjc
618ms
DNS 80ms TCP 1ms TLS 7ms TTFB 283ms
syd
1296ms
DNS 324ms TCP 1ms TLS 6ms TTFB 664ms

What Cutt.ly does

Cutt.ly shortens long URLs into short links, tracks clicks on them and groups them into campaigns, with QR codes and branded domains on paid plans. Marketers use it in emails, social posts and print. Because every short link resolves through Cutt.ly at the moment someone clicks it, the service sits in the path of links that were published long ago.

What an outage looks like

Short links stop resolving: a cutt.ly address returns an error or times out instead of redirecting, and QR codes built on one fail the same way because they encode the same URL. The dashboard may be unreachable, so new links cannot be created and click statistics stop updating. Links published months ago break at the same moment as new ones.

What to do about it

Read status.cutt.ly, which publishes 24-hour, 7-day, 30-day and 90-day uptime for cutt.ly but no per-component breakdown, so it will not separate the redirect path from the dashboard. Test the two yourself: open an existing short link, then sign in. For anything time-critical, publish the destination URL directly rather than waiting, since a link already in circulation cannot be repointed while the service is down.

Is it down for everyone, or just you?

If this page says Cutt.ly is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 17 cities across three regions to find out where it breaks.

Test it yourself

Related services

Bitly
Bitly
L
Linktree
Buffer
Buffer
Hootsuite
Hootsuite

Cutt.ly outage FAQ

Do my existing short links stop working during a Cutt.ly outage?
Yes, and this is what separates a link shortener from most outages. A short link is not a copy of the destination; it is a lookup that happens at click time, so every cutt.ly link already sitting in an email, a social post or a printed QR code stops resolving at the same moment. Content published long before the incident breaks alongside anything created today.
Will I lose my links or my click statistics?
The links themselves are stored on Cutt.ly's side and normally return when the service does, so an outage is usually an availability problem rather than a data one. Click counts are a different question: Cutt.ly publishes no guarantee that clicks attempted during an incident are recorded, so treat any gap in your statistics as unmeasured rather than as zero traffic.
Is Cutt.ly down or is my link just wrong?
Test a link you know is good. Open a second, older cutt.ly link that worked recently; if it also fails, the problem is the service rather than the individual link. A single broken short link while others work usually means that link was deleted or edited rather than that Cutt.ly is down.
Can I recover the destination of a short link while Cutt.ly is down?
Not through Cutt.ly, but often through your own records. The destination lives in Cutt.ly's database, so link previews and expanders cannot resolve it either while the service is unreachable. If you created the link, the original URL is usually recoverable from the campaign, email or document you built it for. Exporting your links periodically is what makes this a nuisance rather than a loss.
Does a Cutt.ly outage affect QR codes I have already printed?
Yes, if the QR code encodes a cutt.ly address. A QR code is just a machine-readable URL, so scanning one during an outage produces the same failure as clicking the link. Printed material cannot be repointed, which is the main argument for putting a domain you control in front of anything that goes to print. Codes encoding the destination directly are unaffected.

How we measure this

  • We request Cutt.ly's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Cutt.ly publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Cutt.ly goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required