LunolyteSeveral services at once
When more services on the same status page go down within minutes of the first, you get the first alert straight away and one follow-up that names the rest. Not a message for each.
How a check works, and what it cannot tell you
What we send, from where, how often, and what has to happen before you get an alert. Including the parts a brochure would leave out.
The checks
What we send, and how often
Nothing is installed on your side. Every check is a request from our server to an address of yours, the same request any visitor could make.
| Check | What we do | How often | Plans |
|---|---|---|---|
| HTTP status | We request your address the way a browser would and look at the status code that comes back. | Every minute on Pro and Agency, every 5 minutes on Starter | Every plan |
| SSL certificate | We connect and read the certificate: until when it is valid, whether it was issued for your name, and whether browsers trust it. | Every hour | Every plan |
| Response time | How long your server takes to answer, held against a limit and against what is normal for that service. | As often as the HTTP check | Pro and Agency, add-on on Starter |
| DNS | We look your domain name up through two independent DNS services, and note where it points. | Every 5 minutes | Pro and Agency |
| Page content | We fetch the page and look for a text you chose. | Every 5 minutes | Pro and Agency |
From a failed check to an alert
When you hear about it
The first check that fails opens an incident and sends the alert. We do not wait for a second check to agree: on a five-minute plan that would be five more minutes of nobody knowing.
1
A check fails
Your address does not answer, or answers with an error. That one result is enough.
2
The incident opens
By itself, with the time and what the check ran into: a timeout, a refused connection, the status code that came back.
3
The alert goes out
To everyone on the account who has alert mail switched on, and on Pro and Agency to the Slack channel, Teams channel or webhook of that status page.
4
How long it can take
A check starts every minute on Pro and Agency and every five minutes on Starter, so something that breaks right after one waits for the next. Then comes the check itself: a site that does not answer at all is given some seconds before we call it a failure. And when our own platform has trouble, a check can be late or missing.
5
It recovers
The check passes again, the incident closes by itself, and you get a message that it is over.
6
On the record
The timeline keeps every step with its time, on your status page and in the portal.
Noise
One outage, one message
Alerting on the first failure means being careful about everything after it. This is what we do so that an alert stays something you read.
A service that keeps going down
The third time a service goes down within an hour we say so, and stop reporting every short interruption. You hear again if it stays down for more than five minutes, and once it has been stable for an hour. Every interruption is still an incident on your status page.
A slow response
Reported once when it starts and once when it is over. Not at every check in between.
DNS and page content
Before either opens an incident we look a second time, twenty seconds later. A domain name has to fail at both DNS services we ask.
Planned maintenance
Announce a window and the service says Maintenance for as long as it lasts. A check that fails inside it opens no incident and sends no alert.
A false alarm
The HTTP check has no second opinion. A hiccup on the route between us and you can open an incident that was not yours. Such an incident can be retracted on request, with the reason on record.
Where from
One location, and what that means
Every check comes from our own monitoring server in Nuremberg, Germany. A result tells you whether your site could be reached from there at that moment, and nothing more.
That has a consequence we would rather state than have you discover. If the connection between Nuremberg and your site fails while the rest of the world can reach you, we report an outage your visitors do not see. And a site that cannot be reached from one country only can look fine to us.
A failure is not yet confirmed from a second location. Checks from more than one location are on our list. Until they exist, this paragraph stays.
The limits
What a check cannot tell you
- Anything behind a login. We request the address exactly as you gave it and add nothing: no sign-in, no token, no header.
- Whether an order goes through. We can tell you that the page your checkout starts on answers and shows the text you expect. Not that a payment completes.
- A page that builds itself in the browser. The content check reads what your server sends and does not run JavaScript.
- The inside of an API answer. An endpoint that answers a plain request is checked for its status, its speed and, if you choose, a text in the answer. We do not read individual JSON fields.
- Ports, pings, cron jobs and servers. Lunolyte checks addresses a browser could open.
- Your phone at night. Alerts go by email, Slack, Teams and webhook. Not by SMS or a phone call.
What a webhook receives
A JSON message per event, for a problem and again for its recovery: the status page and the service (domain_name, service_name, target_url), the status, whether it is_recovery, the severity, the check_type, a message in words, and the cause when the check knows what it ran into.
What we keep, and where
- Servers and databases are in Nuremberg, Germany. Backups are made every night, stored encrypted at a second location in the European Union, and restoring from one has been tested.
- Signing in works with a link sent to your email address. There is no password to leak.
- Card details go from your browser to Stripe, our payment provider, and never reach our servers.
- Of a page we check we keep the result and not the page: the status code, how long it took, whether the text was there.
- Single measurements are kept for seven days, then summarised per hour and per day for as long as the history of your plan runs.
We hold no security certification and will not suggest that we do. What we do is written out in the Data Processing Agreement and the Privacy Policy.
Look at one that is running
Our own status page is checked this way, and it is public on the bad days too.