The shop application
app.torqix.netThe board, tickets, estimates, inspections, texting, parts, invoicing and the time clock. If this is down, your shop is running on paper.
Status
This page will not tell you Torqix is up.
It cannot. It is served by the same infrastructure the product runs on, so on the day that infrastructure is having a bad morning, this page is either having the same bad morning or it is cheerfully reporting that everything is fine. Both of those are useless to you, and the second one is worse than useless.
So there is no green tick here and there will never be one. What you get instead is the truth about the monitoring: what we watch, what genuinely watches it today, what does not exist yet, how you find out when something breaks, and every incident we have had — including the one nothing detected.
Scope
Everything that can be down.
Not everything called Torqix matters equally to you at four o’clock on a Friday. In rough order of how much your day depends on it:
The customer portal
portal.torqix.netThe page your customer opens from a text to read an estimate, approve work line by line, and sign. If this is down, approvals stop and you are on the phone.
This website
torqix.netMarketing, pricing and signup. The least important thing on this list, and the only one that would still be up if everything else were not — which is exactly why the real status page is not hosted here.
The platform back office
no public address, deliberatelyOurs, not yours. It is monitored anyway: if we cannot see the platform, we cannot see your incident.
Outbound messaging
no public address, deliberatelyTexts and emails leaving Torqix. These pass through providers we do not own, so an outage here can be somebody else's and still be your problem.
Monitoring
What watches it — and what doesn’t yet.
2 of these 6 are running today. The rest are a purchase decision with a price attached and a date that has not been set. Rather than describe the whole list in the present tense and let you assume, each one says which it is.
Speed budgets on every build
Running todaySix journeys — sign-in, opening the board, opening a ticket, search, and the amount of code your browser has to download to see a board — are measured on every single change, against fixed ceilings and against the last known good result. A change that makes the product measurably slower does not merge. This is the part of speed monitoring that is genuinely running today.
A prober that measures production from outside
Running todayA small tool that loads the real public pages from outside our network and reports how long each stage took, including which region served the request. It is written, it works, and it is run by hand. Being run by hand is why the incident below lasted as long as it did.
Uptime checks from several places, every minute
Not built yetEach surface above, checked continuously from outside our infrastructure by a company that is not us, so an outage on our side cannot also take out the thing that reports the outage. This is bought, not built, and it has not been bought yet.
A robot that runs a whole shop day, hourly
Not built yetNot "does the page load" but "can a repair order still be opened, priced, approved and invoiced" — run every hour against a test shop, in production, so a broken approval flow is caught by us at nine minutes past rather than by you at four o'clock.
Timing from real browsers, in real shops
Not built yetOne test shop on a good connection is not forty shops on shop wifi with twenty tabs open. Timing collected from real sessions, attributed to screens rather than to people — never to a customer, a plate or a search you typed.
Something that wakes a human up
Not built yetAn alert that rings a phone at three in the morning, rather than an email read at eight. Until this exists, the honest description of our monitoring is: the owner notices.
Incident communication
How you find out something is wrong.
In the order you will actually encounter them, and with the rule that governs what we are allowed to write in each.
A banner inside Torqix
A message across the top of the app, which we can put up in about thirty seconds without shipping a release. This is the fastest channel and the one that reaches the person who is actually mid-ticket. It is also the only one that may carry detail specific to your shop, because it is only shown to your shop.
The independent status page
Once it exists: the running record of what is degraded and what is fixed, hosted somewhere that stays up when we do not. That page, not this one, is where you should check during an outage — and the link will be printed at the top of this page the day it is real.
An entry here, afterwards
Anything that affected shops gets written up below, with what happened, how we found out, and what changed so it cannot happen the same way twice. Including the ones that make us look bad — especially those, because the interesting part of an incident is almost never the fix.
What none of them will ever say
Public incident text never names a shop, a customer, a plate or a vehicle. “Approvals were failing on the customer portal” is a status update; anything that identifies whose approvals is a privacy incident wearing a status update's clothes. Detail about your shop specifically goes to your shop, in the app.
History
Every incident, since there have been any.
This list is short, and you should read the shortness carefully: Torqix has been running one real shop. An empty or near-empty incident history from a product with one customer and no uptime monitoring is not evidence of reliability. It is evidence that not much has been watched yet.
- Resolved
Every database query was crossing the country
Torqix was not down. It was slow, everywhere, all the time — worst on sign-in and on the board, which ask the database for many things in a row. The servers running the application had defaulted to a region on the east coast while the database sits on the west, so every single question and answer made a round trip across the continent and paid roughly 60 to 80 milliseconds for the privilege. A screen that asks a dozen questions paid it a dozen times.
- Affected
- The shop application · The customer portal
- How long
- Not known. Nothing was measuring it, which is the point of the entry.
- How we found out
- A person said it felt slow. Nothing automated found this, and nothing automated could have: on a build server the database runs on the same machine as the application, so distance is always zero and the speed budgets described above stay green through exactly this fault.
- The fix
- The application servers were pinned to the same region as the database.
- So it cannot recur
- Server region and database region are now treated as one decision rather than two: a new application deployed without an explicit region is a bug, and if the database ever moves, everything moves with it in the same change. It is written down in the runbook in those words.
Related
We are not selling you an uptime guarantee.
There is no contractual uptime number and no service credits, because a company this new should not be selling an SLA and promising one we cannot measure would be the first dishonest thing on this site. What we will commit to in writing is on the Fair Terms pledge, and what has shipped is dated on the changelog.