Live status, published from outside our own infrastructure.
Status published on the same infrastructure it reports on says everything is fine for exactly as long as it can say anything at all. Ours is published from somewhere else, so it can still answer when we cannot. Open status.attergo.com for the live answer and the incident record.
What is monitored
Three components, reported separately, because "the platform is up" is not a useful sentence to somebody whose claims are flowing while the console will not load. Each check asserts a string from the response as well as a status code, so a stale deployment serving a healthy 200 with none of the page in it still registers as down.
| Component | What it is | What the check asserts | Interval |
|---|---|---|---|
| Attergo.com | This marketing site | Status code and a line of the page body | Every 60 seconds |
| Attergo App | The application at app.attergo.com | Status code and the shell actually rendering | Every 60 seconds |
| Attergo API | The API, through the same path a browser takes | Status code and the health response body | Every 60 seconds |
Check it yourself
The application's health endpoint is public and unauthenticated. It returns a small JSON body and nothing about any tenant. Open it in a browser: it is the exact address, and the exact response, the API monitor checks every minute.
A 200 there tells you the API answered. Queue movement and the health of one specific connection are on the status page, and in your own console under the connection that concerns you.
When something is wrong
Incidents are recorded on the status page, including the ones that resolved before anybody wrote in. Your contract carries the notification timeline and a named contact, and an incident report you can hand to your own counsel.
Commitments and the record
Availability lives in your agreement. A service level commitment is contractual and carries remedies, so it belongs where you can enforce it. Enterprise agreements carry one. Ask for it in writing during procurement and we will put it in front of you.
One incident history. The status page holds the record, written by the monitoring that observed it. There is no second version of it on this site to disagree with.
This page is checked against the running internet. Every address on it is fetched before it can ship. If the status page stops serving, or stops reporting the site, the application and the API separately, our build fails and the release does not go out.
The same discipline runs across the security documentation: published claims are compared to the live system on every build, so a sentence here cannot outlive the thing it describes.
Connect one store. We will tell you what the month cost you.
Read-only credentials you can revoke. We come back with the fills that went out under cost, the services you could have billed, and the fills an auditor would ask about.