Red Kite / Who we are
The people who have to answer the phone at four in the morning.
Red Kite is built by a small team of systems engineers. We run it on our own machines before anybody else runs it on theirs, and every decision on this page was made by somebody who has been woken up by the failure it prevents.
The short version
We are a small independent team of systems engineers in the United Kingdom. We build one product: Red Kite, a dead man’s switch monitor for servers, NAS boxes and PCs. It is free while it is in beta, with unlimited machines and no account.
We are not venture funded, we are not hiring a sales team, and we do not host or monitor anything for anybody. You install it on your own server, and it runs without us. There is no account with us, nothing phones home for permission, and if we disappeared tomorrow the copy you are running would carry on working.
That last sentence is doing real work, so we mean it literally. There is no licence check to fail, because there is no licence check. See the questions if you want the detail.
Why it exists
Every one of us had, at some point, the same bad morning: a machine that had been dead for days, and a monitoring system that never said a word. Not because the monitoring was broken — because it was on the same site. Same power, same broadband, same cupboard. When the thing it watched went down, it went down too, and silence from a monitor reads exactly like a quiet night.
The fix is not a better dashboard. It is an inversion. Machines reach out to a hub somewhere else, and the alarm is the message that does not arrive. A monitor that has to reach in reports “all well” when its own network breaks. A monitor that waits to be reached reports trouble when anything between the machine and the hub breaks — which is the honest answer, because if we cannot hear from a machine, we do not know that it is well.
It also has a practical consequence that turned out to matter more than we expected: nothing needs a port open. No VPN, no port forwarding, no static IP. A server in a cupboard behind a domestic router is as watchable as one in a data centre, and that is most of the servers we have ever been asked to look after.
Four decisions we will not sell
These are written down in the specification as non-negotiable, which means they are not subject to a customer request, a big order or a bad quarter. We are listing them here because the way to judge a small software team is by what they have decided in advance to refuse.
The agent never accepts instructions
It sends. It does not receive anything but a suggested check-in interval and, when one is rotated, a replacement token. No remote command execution, no “run this script”, no self-update that fetches code. The reasoning is arithmetic rather than caution: an agent that can be told what to run turns one compromised hub into administrative access to every site it is installed on. That is not a monitoring system, it is a botnet with a support contract.
The hub never connects to a monitored machine
Not over SSH, SNMP, WinRM or anything else, and not even to confirm a machine is “really” down. That confirmation is exactly what the design trades away, knowingly. We cannot tell “the machine is off” from “the broadband is down” — so we do not pretend to. The hub says what it knows: we have not heard from this since 04:12.
The hub timestamps, never the agent
Machines have wrong clocks, and across eighty of them there are always some. The agent’s own clock travels as a fact, so we can tell you a machine is 41 minutes behind — but it is never the basis of a decision about whether something is overdue.
Unknown is never good news
Anywhere a reading is missing, stale or unreachable, we say so, in its own colour, with words beside it. A figure the agent could not gather is “cannot report”, never zero — because an empty gauge resting at zero and a healthy zero are the same picture, and the difference between them is “we cannot see the disk” against “the disk is fine”.
A monitoring system that renders “cannot tell” as “fine” is worse than having none at all, because it is believed. If you ever catch Red Kite doing it, that is a bug of the most serious kind we have, and we would like to hear about it — contact@redkite.info.
The full security position, including tokens, what a check-in may contain and how customers are kept apart, is on the security page.
We run it ourselves first
Every version goes on our own machines before it goes anywhere else, and the hub watches itself as an ordinary machine in its own fleet. That is not a slogan about craftsmanship; it is the only way we find the failures that matter.
Two examples, both of which reached us because we were the customer. A hardened systemd unit turned out to be measuring its own sandbox rather than the machine, so the agent announced that a perfectly healthy server had switched itself read-only — the most alarming sentence this product knows how to say, on a machine that was fine. And a raw SQL query with a regular expression in it was silently matching nothing, so every machine reported that it had never rebooted. Both were found by us, on our own fleet, before a customer ever saw them.
You are welcome to read the agent before it goes near a server. It is a shell script on Linux and PowerShell on Windows, deliberately: no compiled binary, no runtime to install, and nothing you cannot audit at three in the morning without a build machine. You get it in full and unobfuscated. If your policy is that nothing unread goes on a customer’s machine, say so while you are evaluating and we will send it over before you buy rather than after.
What is built, and what is not
We would rather lose a sale than win one on a feature that does not exist yet. The front page carries a section saying what is still being built, and it is kept accurate against the actual state of the code rather than against what would be convenient to claim.
Two things in particular are worth being blunt about, because they are the ones a careful buyer will ask about:
- Deep readings are gathered and shown, but do not yet raise their own incidents. If a disk is filling or a mirror is degraded, you will see it on the machine’s screen and in the fleet list. Thresholds that alert on their own are being built and are not finished.
- Per-customer screens and alert routing are being built. The tenancy filter is enforced in the database from the first migration — that part is real and is described on the security page — but the screens that would let a customer log in and see only their own machines are not there yet.
Silence about an unfinished feature is a small lie that gets discovered at exactly the wrong moment. We would rather you knew now.
What we will not do
Some of these would make us money. They are listed anyway, because knowing where a supplier has drawn its lines is worth more than knowing what it has promised.
- We will not add remote access to the agent. It is a genuinely useful feature and people do ask. It belongs in a separate tool with its own authentication, its own audit trail and its own explicit customer consent — not bolted onto the one piece of software that runs unattended on every machine you own.
- We will not collect content. A check-in carries figures: byte totals, counters, up and down states, how many of something there were. No file names, no user names, no process command lines, no log message text. The test we apply to anything new is: if this database leaked, what would the customer mind?
- We will not add a licence check. Not now, while it is free, and not later if it stops being free. The software has no way to stop working, and nothing installed during the beta will ever be switched off from our end. That is a deliberate constraint on us rather than a favour to you.
- We will not pretend to be better than the free tools. Zabbix is free and mature. So are Uptime Kuma, Checkmk Raw and Nagios Core, and they are good software with years of work behind them. What Red Kite offers against them is a narrower job done more honestly — not more features, and not a longer track record, because it does not have one yet.
Why it is free, and what happens later
Red Kite is free while it is in beta. No subscription, no account with us, no card and no trial clock. You install it on your own server and watch as many machines as you like.
That is not generosity, and we would rather not dress it up as generosity. It is free because it is not finished, and because the only thing we cannot get on our own hardware is evidence of how it behaves on yours. We have run it on our own machines for as long as that usefully teaches us anything. Everything we learn from here has to come from somebody else’s.
So the exchange is plain: you get working software for nothing, and we would like to hear what it got wrong. A figure it reported that was not true. An alert that never arrived. An alert that arrived and should not have. A disk it could not read.
It will probably not be free for ever
We would rather say that now than surprise you later. At some point Red Kite may well have a price on it, and if that happens we will say so on the website well before it does rather than letting people find out at renewal time, which is a thing that does not exist here anyway.
Anything installed during the beta keeps running. There is no licence check to fail, because there is no licence check, and we are not going to add one to software people installed while it was free. It cannot expire, degrade, nag or stop watching your machines, and that stays true whatever we decide about pricing.
Provided as it is
It comes with no warranty of any kind. That is the ordinary footing for software given away, and on a monitoring tool this early it is also the honest one: we do not yet have enough machines behind us to promise it catches everything.
The only thing it costs to run is hosting the hub, roughly £6 to £20 a month, and that goes to whichever company rents you the server. We do not take a part of it and we cannot see it.
How to reach a person
contact@redkite.info reaches an engineer, not a ticket queue. That is a consequence of being small rather than a service promise, and it is worth saying which it is.
Sensible things to write about: whether this is the right tool for what you are trying to watch — we will tell you honestly if it is not; a security question you want answered before you install anything; a request to read the agent source before you buy; or something on this site that is wrong, unclear, or overclaiming.
If you have found a security problem, please write to the same address and say so plainly in the subject line. We would far rather hear it from you than from a customer.