One binary. No agent to babysit.
Checks from the outside tell you whether your customers can reach a service. The agent tells you why they cannot — and what is about to go wrong before they notice.
The machine itself
Disk per filesystem, memory that is genuinely available, CPU, and load read against the core count. With 24 hours of history drawn as a trend.
Its containers
Through the Docker socket: containers and their healthchecks, memory and CPU against each container's own limit, Swarm services and whole stacks. Inside a Kubernetes cluster: workloads, nodes, crash-looping pods and CronJobs.
What the outside cannot reach
HTTP, HTTPS, ping and TCP sent from inside: private addresses, internal names, admin ports behind the firewall, self-signed certificates.
Anything you can script
Your own scripts, or any Nagios plugin. Exit code becomes the status, the first line of output becomes the message. And whether last night's backup landed: how old its newest file is, and whether it is big enough. See the guides.
Installing it takes about a minute
A single static binary with no runtime and no dependencies, packaged for Debian, Ubuntu, Fedora and RHEL, or on its own for anything else. Get a token in Gryphon, install the agent, give it the token. It connects out, so there is no port to open and no certificate to manage.
On Linux
-
1
Install the
.debor.rpm, run the install script, or copy the binary to the host. amd64 and arm64. - 2 In Gryphon, choose Connect an agent on the host's page and copy the token it shows.
-
3
Run
sudo gryphon-agent enroland paste the token. It checks the token with Gryphon there and then, and starts the agent; the host's page shows it connected within seconds.
Under an orchestrator, every setting also reads from a file, so the token can be a mounted secret rather than an environment variable.
On macOS
Gryphon Agent is a menu bar app. It shows whether it is connected, takes its token from Enter Token… in its menu, and can start when you log in. The same checks, without a terminal, and no tunnel to set up.
On Windows
The same agent, built for Windows, as a Windows service. One command from an administrator's PowerShell installs it and a settings folder only administrators can change; a second gives it its token, and it starts with the machine from then on.
Where to run it
On the machine you actually mean to watch. Its disk, memory and CPU readings are the machine's — inside a container they would still be the machine's, not the container's — so one agent per node, not one per service.
One agent covers everything on its node: the host readings, every container on it, and any number of network checks sent from it. The one on a Swarm manager also answers for your Swarm services and stacks across the cluster.
A Kubernetes cluster is the exception: one agent runs inside it as a pod, reads the cluster's API, and answers for the whole cluster, nodes included. Installing it is one manifest.
What it deliberately does not do
It holds no thresholds
The agent reports a reading and nothing more. The server decides what the reading means, so changing a warning level in the dashboard takes effect on the next check, on every host, with nothing to redeploy and no configuration file to keep in sync.
It opens no door on the machine
The agent makes one connection, out, to Gryphon, over HTTPS, and takes its checks down that connection. Nothing listens, so there is nothing for anyone on the internet — or on your network — to connect to. It proves which host it is with a token issued for that host, which we store only as a one-way hash: we cannot show it again, and replacing it disconnects the agent that held the old one.
It decides for itself what may run
Script checks run only executables already present in a directory the host's administrator names, by bare file name. Neither a Gryphon sign-in nor the agent's own token can make it run anything you did not put there — and script checks are off entirely until you name that directory. File checks are held the same way: they look only inside folders the administrator names, and are off until they do.
Your databases stay off the network
A database bound to localhost is checked by the agent on that machine, so its port never has to be opened. If the check signs in, the password is stored encrypted on our side and reaches the agent only over HTTPS, with each check. Or check it with no credential at all: a bare handshake still tells a server that is up from one still recovering.
None of this has to be taken on trust. The agent's source is public, under the MIT licence, and the Linux and Windows releases are built from it on GitHub, where anyone can watch the build. Read the source.
Fourteen days free. Then from $4.99 a month.
The agent, the dashboard, the apps and every check but the five for Kubernetes are in every plan. The plans differ in how much you watch, how often, from where, and how many people and status pages they include. Compare the plans. Cancel any time.
Already have an account? Sign in