Owl Keeper

Features

An uptime check is the easy half.

Anything can tell you a server stopped answering. The failures that actually cost you — a certificate that lapsed on a Sunday, a domain nobody renewed, mail that quietly stopped being trusted, a noindex that shipped by accident — all answer a perfectly healthy 200. Owl Keeper watches for those on the same page, for every site, on every plan.

What most uptime tools leave to you

The first two rows are the category. The rest is why this exists.

The question A typical uptime tool Owl Keeper
Is the site answering? HTTP, TCP and mail checks, on your schedule. Yes Yes
Is the certificate about to expire? And whether the chain is complete and actually covers the hostname. Yes Yes
Is the domain about to lapse? Read from the registry, not guessed from a WHOIS scrape. Sometimes Yes
Has the registrar lock come off? The signal that precedes a domain being taken. Also DNSSEC. No Yes
Will your mail reach an inbox? SPF, DKIM, DMARC, MTA-STS and BIMI — with SPF lookups counted through every include. No Yes
Is the site telling search engines to go away? A stray noindex or a staging robots.txt that shipped to production. No Yes
Are the response headers doing anything? HSTS, CSP, cookie flags, and whether plain HTTP still answers. No Yes
Is anyone reading your cookies? A session cookie without Secure travels in clear text the first time somebody types the address without https. No Yes
Can an AI agent use this site? llms.txt, an API catalogue, an MCP server card — and which AI crawlers the robots file has an opinion about. No Yes
Does the contact form still take a submission? Submitted for real, from a marked address, so a form that has quietly stopped delivering is caught in hours. No Yes
Did the nightly backup actually run? The job calls a URL when it finishes. You hear about the night it does not. No Yes
What changed since last week? Only differences are written down, so the history is the list of things that moved. No Yes

Mail authentication

The checks other people sell as a product of their own

Mail authentication is the failure with the longest fuse: nothing breaks, nothing alerts, and invoices simply stop arriving. It is normally a separate subscription, from a separate vendor, at a separate price. Here it is one of the daily passes over every domain you add.

SPF, counted properly

Every include is followed and the DNS lookups are counted on the way. Passing ten is a permanent error that leaves the record looking completely reasonable — it is the single most common way a domain that used to deliver stops.

DKIM and DMARC

Whether the selectors you publish resolve, and what your DMARC policy actually instructs a receiver to do. A policy of none is reported as what it is: published, and doing nothing.

MTA-STS and BIMI

The newer half — whether mail to you is required to travel encrypted, and whether your logo is allowed to appear next to it. Reported as facts, never as faults.

MX that resolves

The records exist, the hosts behind them exist, and the mail server actually answers a greeting and offers STARTTLS.

Blocklists

Whether the domain or its sending host has turned up on a list receivers consult before accepting anything from you.

Told once, not daily

A broken record stays broken until somebody fixes it. You are told when it breaks, not every morning until you do — which is how a reminder becomes something people filter away.

Scheduled jobs

The backup nobody noticed had stopped

A cron entry is lost in a server migration and the nightly backup quietly stops. Nothing breaks, nothing alerts, and the site carries on answering 200 for months — until the morning somebody needs to restore, which is the most expensive possible day to find out.

This is the one check here that runs the other way round. Your job calls a URL when it finishes; you are told when a call does not arrive.

One line in a crontab

Add a curl to the end of the job you already run. There is nothing to install, no agent, and no library to keep updated.

Works behind a firewall

Nothing is requested from this side, so a job on a machine with no public address — a build box, a laptop, a client's server — reports in exactly the same way.

A grace period, so it is not noise

A job that takes four minutes is not late at four minutes past. You set how much slack a run gets before it counts as missed.

The alert says when it last ran

Not "the job is down" but "the last run was nine hours ago", which is the difference between a question and an answer.

How long the run took

A job that reports its own duration gets a history of it, so the week it started taking four times as long is visible before it starts failing.

Told once, not every night

A job that has stopped stays stopped until somebody fixes it. You hear about it when it breaks, not every morning until you do.

Response security

Graded, not listed

Anything can print the headers a site sends back. The useful question is which of them are missing, which are set to something that does nothing, and which one of those is a hole rather than a hardening job you have not got to yet.

HSTS with a number that means it

Present is not the same as effective. A max-age under about six months is forgotten by a browser sooner than most people renew anything, and preload lists refuse it — so a short one is reported rather than ticked off.

Cookies, which is where the hole usually is

A session cookie without Secure travels in clear text the first time somebody types the address without https. That is the one finding here treated as a problem; the rest are hardening, and the difference is the point.

A content policy, and frames

Whether a Content-Security-Policy exists at all, and whether anything stops the site being framed — by the header or by the policy, since either will do and only one of them is the old way.

What the server admits to

Server and X-Powered-By carrying version numbers is free reconnaissance for anybody scanning for a known bug in exactly that release.

Whether plain HTTP still answers

A redirect to HTTPS is fine. Port 80 refusing the connection outright is better, and the difference is reported rather than flattened.

A header that disappears is an event

A policy that was there last week and is not there today is written into the site history, because that is a deploy nobody meant to make.

AI and agent readiness

Which of your clients are ready to be read by something that is not a person?

A question nobody can currently answer about their own estate, and one clients are starting to ask. Every site you add is checked for the conventions an AI agent looks for, across four areas: whether it can be discovered, whether its content can be read, what it says about crawlers, and what it can actually do.

Recorded as facts, never as faults. Publishing none of this is an ordinary website, not a broken one — and for plenty of clients, refusing the crawlers is the brief.

llms.txt and Markdown

Whether there is a plain-text summary at the root, and whether the pages themselves will answer in Markdown when something asks for it instead of serving a page of framework markup.

Eighteen AI crawlers by name

GPTBot, ClaudeBot, PerplexityBot, Google-Extended and the rest. Naming one at all is the signal — it means somebody decided, rather than inheriting whatever the default was. Whether they allowed or blocked is reported, never judged.

Content Signals

The newer convention for saying what a crawler may do with what it takes: search, train, or answer directly. Published or not published, either way it is worth knowing which.

An API catalogue

Whether /.well-known/api-catalog exists, which is how a site tells an agent what it offers rather than leaving it to guess from the HTML.

MCP and agent skills

A server card at /.well-known/mcp, or a skills index — the two ways a site can hand an agent its own procedures instead of hoping they are inferred.

Signed requests

Whether the site is set up to verify HTTP message signatures, which is how it will eventually tell a real agent from something wearing its user agent.

Certificates and domains

The two dates that take a site off the internet

Certificates, checked past the expiry date

When it expires, who issued it, whether the chain is complete, and whether it covers the hostname it is actually serving — including wildcards, which cover one level and not two. Warnings at 30, 14, 7, 3 and 1 days.

Registration, read from the registry

Expiry, registrar and status straight from RDAP rather than scraped from a WHOIS page. Warnings start at 60 days, because a lapsed domain is slow and expensive to recover where a certificate can be reissued in minutes.

Registrar lock and DNSSEC

A lock coming off is the step before a domain is moved. Seeing it as a change on a Tuesday is the difference between a phone call and a recovery.

Nameservers and delegation

Who is authoritative for the domain, and whether that answer has changed since yesterday. Recorded alongside everything else on the site, not on a page of its own.

Alerts

An alert you can afford to believe

A monitoring tool is only worth having if you still read its messages in month six. Everything here is arranged around not spending your attention.

Refused is not down

A firewall answering 401, 403 or 429 tells you nothing about whether visitors can reach the site. It is reported as the checker being turned away, in amber, and the alert names the user agent to allow so you can fix it in one step.

Confirmation before the interruption

Nothing is called down until it has failed as many times in a row as you decided. One dropped packet on a flaky network never becomes a message.

Recovery, not just failure

You are told when it comes back and how long it was gone, so the incident closes itself rather than leaving you to check.

Slack, Discord or signed JSON

Paste a Slack or Discord URL and messages are formatted for it. Anything else receives JSON signed with an HMAC, so a receiver can tell our POST from anyone else who learned the address.

In the language of whoever reads it

Alerts are written in the language of the account they are addressed to — so one person can be told in Spanish while a colleague gets the same alert in English.

Pause without losing history

Planned maintenance skips the schedule instead of generating a false incident, and nothing already recorded is thrown away.

Looking after other people's sites

A site is the unit, not a monitor

A client with a website, an API, a mail server and a certificate is one thing to look after — and four billable rows in a tool that charges by the row. Here a site carries its certificate, its registration, its DNS and its mail records at no extra count.

Tags that filter an estate

Tag by client, by hosting provider, by whatever you actually think in, and pull sixty sites down to the four you are being asked about.

A status page safe to send to a client

Uptime, what is answering, and when the certificate and registration renew — on an unguessable link that never shows monitor names, addresses, or anything from the security checks. Withdraw it and the link stops working.

A history that is only changes

A check that finds the same thing as yesterday records nothing. What you can show a client is the list of what actually moved — the issuer, the nameservers, the DMARC policy — instead of a year of identical rows.

Nothing tracking your clients

No analytics, no tracking pixels, no advertising and no third-party scripts anywhere in the product. There is nothing here to put in a data processing agreement that you would rather not.

Every check, on every plan

Nothing on this page is held back for a higher tier. The plans differ by how many sites you watch and how often, never by what is looked at.