Check it yourself
A status page maintained by the vendor is the least reliable page on any vendor’s site, because it is updated by the people having the bad day. So nothing here is updated by hand: the rows below are a live check your own browser runs against our endpoints as this page loads, and the same check is one command away if you would rather not take our word for the result.
The two endpoints
Both answer without authentication and both are safe to poll from your own monitoring. A 200 means the service is running and can reach what it depends on.
- IngestChecking…
- APIChecking…
Checked by your browser as this page loaded, against the two addresses below.
A row reading “No answer” means this browser could not complete the request. Usually that is the service — but a corporate proxy, a browser extension or your own network produces exactly the same result, which is why the commands below are the check that settles it.
curl -sS -o /dev/null -w "%{http_code}\n" https://ingest.snagspy.com/healthz
curl -sS -o /dev/null -w "%{http_code}\n" https://api.snagspy.com/healthzPoint your own uptime monitor at these. A vendor status page you have to visit is a notification you will not receive; a check inside your own alerting is one you will.
What breaks when what fails
| If this is down | What happens to you |
|---|---|
| Ingest | New telemetry is not accepted. Your SDK and your collector buffer and retry, so a short outage costs latency rather than data; a long one costs whatever your exporter’s queue could not hold. |
| API | The dashboard cannot load and the REST API does not answer. Ingestion is a separate service and keeps accepting telemetry. |
| The marketing site | These pages are static files at the edge. They can be up while the platform is down, which is why this page tells you to check the endpoints rather than to trust the fact that you are reading it. |
How an incident reaches you
By email, to the address on the account, from a verified sending domain. The check at the top of this page is live, but it is a check and not a history: there is no incident archive and nothing to subscribe to yet, so your own monitor pointed at those two addresses will always tell you sooner than we can.
If something looks wrong and the endpoints answer, write to [email protected] with the time and the project. A report from a customer during an incident is worth more than any dashboard we have.
What is protected, and how
- All inbound traffic reaches the platform through an encrypted tunnel; the host exposes no ports directly to the internet.
- Backups are taken and are stored off the disk they exist to protect, which is the only arrangement in which a backup is a backup.
- Retention ceilings are applied by a scheduled job and again when data is read, so a late job cannot resurrect data past its window.
- Telemetry over a plan is announced rather than refused, so an incident that produces a spike does not also lose you the evidence of it.
Read the security page next
This page is about availability. Encryption, access, retention and the full list of third parties that ever see your data are documented separately, and in more detail.