Skip to main content
TestRail logo

Is TestRail Down?

No — TestRail is up

Reachable from all 8 checked regions

Average response time: 1315ms

Last checked · checks run every 6 hours

Official status page: https://status.testrail.com

TestRail uptime

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

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

30-day history

19-day clean streak
Sep 14: no data
Sep 15: no data
Sep 16: no data
Sep 17: no data
Sep 18: no data
Sep 19: no data
Sep 20: no data
Sep 21: no data
Sep 22: no data
Sep 23: no data
Sep 24: no data
Sep 25: 100.00% uptime, 16 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, 31 checks
Sep 30: 100.00% uptime, 32 checks
Oct 1: 100.00% uptime, 32 checks
Oct 2: 100.00% uptime, 32 checks
Oct 3: 100.00% uptime, 31 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.

ams
227ms
DNS 33ms TCP 27ms TLS 24ms TTFB 119ms
lhr
155ms
DNS 45ms TCP 16ms TLS 14ms TTFB 99ms
nrt
2452ms
DNS 495ms TCP 242ms TLS 245ms TTFB 1239ms
ord
921ms
DNS 114ms TCP 101ms TLS 102ms TTFB 427ms
sin
1643ms
DNS 326ms TCP 162ms TLS 165ms TTFB 829ms
sjc
1183ms
DNS 33ms TCP 141ms TLS 144ms TTFB 474ms
syd
2845ms
DNS 149ms TCP 335ms TLS 338ms TTFB 1169ms
yyz
1096ms
DNS 307ms TCP 96ms TLS 99ms TTFB 613ms

What TestRail does

TestRail is test management software. QA teams use it to write test cases, run test plans and record results, both manual and from automated suites that post through its API or the TRCLI command-line tool. It comes as TestRail Cloud, hosted by the vendor, or TestRail Server on your own infrastructure. Its Jira integration links results to issues, and CI pipelines often upload JUnit results to it.

What an outage looks like

Pages load slowly or fail with 500 errors, or the instance shows maintenance mode instead of your projects. Past incidents also brought gateway errors, 403 Access Denied messages, attachment errors and a DNS fault that blocked access. The API returns 5xx errors, so CI jobs that upload results with TRCLI exit non-zero. Jira problems show up separately, as failed authentication or 500 errors when syncing.

What to do about it

Check the TestRail Cloud and TestRail Jira Integration (Cloud) rows on status.testrail.com; the page lists only Cloud components and does not cover TestRail Server installs. Your client owns retries: TestRail's API docs say applications must handle 5xx errors and retry later. Keep your JUnit XML artifacts and rerun TRCLI once service returns, using --run-id to append to the existing run.

Is it down for everyone, or just you?

If this page says TestRail 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

Jira
Jira
BrowserStack
BrowserStack
Sauce Labs
Sauce Labs
GitHub
GitHub

TestRail outage FAQ

Will TestRail retry failed result uploads?
No, the API leaves retries to your client. TestRail's documentation says applications using the API are responsible for handling 5xx errors and should retry later. TRCLI retries automatically when throttled by the rate limit, but a job that exits non-zero during an outage has not uploaded. Keep the JUnit XML as a pipeline artifact and rerun TRCLI with --run-id once the instance is back.
Why does the TestRail API return 409?
A 409 means your TestRail Cloud account is undergoing daily maintenance, not that the service is down. TestRail's API documentation lists 409 as a Cloud-only code for this, next to 429 for rate limiting and 500 for server errors. Treat a 409 as a pause and retry later, and check status.testrail.com only if errors outlast the maintenance or turn into 500s.
Why am I getting 429 errors after TestRail recovers?
Because TestRail Cloud limits API calls per instance. The limit is 180 requests a minute on Professional and 300 on Enterprise, and a 429 response carries a Retry-After header saying how many seconds to wait. Many pipelines retrying at once after an outage can reach it. TestRail recommends bulk endpoints such as add_results_for_cases over single-result calls. TestRail Server has no built-in limit.
Does the TestRail Jira integration fail separately?
Yes, it has its own row on the status page. Status.testrail.com tracks TestRail Jira Integration (Cloud) apart from TestRail Cloud. In March 2026 an authentication fault caused failures connecting to Jira and syncing data, including 500 errors, for several days while TestRail itself stayed up. Users had to reauthenticate with Jira inside TestRail for the fix to take effect.
Is testrail.com being down the same as TestRail being down?
No. This page checks www.testrail.com, the company website. TestRail Cloud instances run at their own addresses, which TestRail's documentation shows in the form yourinstance.testrail.io, and the website is not a component on status.testrail.com. The website can load while your instance is failing, and the reverse, so check your instance URL and the TestRail Cloud row.

How we measure this

  • We request TestRail'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 TestRail 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 TestRail 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