# updo watches your sites from a terminal, thirteen AWS regions or both > Updo is a Go command line tool that monitors website uptime, response time and SSL expiry with a terminal UI, JSON logging, Prometheus metrics, webhook alerts and optional multi-region checks from AWS Lambda. It is MIT licensed, and the last push was on 2026-05-26. **Owloops/updo** — Uptime monitoring CLI tool with alerting and advanced settings - Repository: https://github.com/Owloops/updo - Stars: 1,138 · Forks: 61 - Language: Go - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/owloops-updo ## One command, three kinds of output Updo is a command line tool for monitoring website uptime and performance, providing real-time metrics on website status, response time, SSL certificate expiry and more, with alert notifications. The usage is short: ```bash # Monitor URLs updo monitor [options] updo monitor # Using configuration file updo monitor --config # Generate shell completions updo completion bash > updo_completion.bash ``` The output modes are the second thing the feature list calls out: an interactive TUI, simple text output, or structured JSON logging. The TUI is built on gizak/termui, which is in the dependency list, and the simple mode is what the --simple flag selects, with --log producing JSON. The options are grouped in the README the way a user would look for them. Basic ones are --url and --config for the target, --refresh for the check interval in seconds with a default of 5, --timeout for the request timeout defaulting to 10, --count for the number of checks where 0 means infinite, and --simple for text output. HTTP options cover --header for custom headers, --request for the method defaulting to GET, --data for a request body, --skip-ssl, --follow-redirects and --accept-redirects, and --assert-text for an expected response string. The --assert-text option is worth a note, because it turns a status code check into a content check. A site that returns 200 with an error page is down in every way that matters to a user, and asserting on the body catches that. --only and --skip filter targets by name, which is what makes the config file with many targets usable, since the README's example runs --config example-config.toml --only Google,GitHub. The Go module is github.com/Owloops/updo with go 1.24.0, and the primary language is Go. ## Multi-region monitoring means Lambda and an embedded binary The multi-region feature is the one that distinguishes updo from a curl loop, and the implementation is visible in the build system. The --regions flag takes AWS regions as a comma separated list or the value all, and --profile selects the AWS profile for the remote executors. The feature list says the tool can deploy across 13 global regions for worldwide monitoring coverage, and the repository has a lambda/ directory holding the Lambda source, with lambda/lambda.go named as the source in the Makefile. The mechanism is that updo ships the Lambda code inside its own binary. The Makefile has a build-lambda target that compiles lambda/lambda.go for GOOS=linux and GOARCH=arm64 with CGO_ENABLED=0 and the build tag lambda.norpc, producing aws/bootstrap and then zipping it into aws/bootstrap.zip, and the build target embeds the result in the main binary. The Go dependency list backs this up, with the AWS SDK v2 pulling in the Lambda, IAM and STS services, which are the three you need to invoke a function, grant it permission and assume the role to do so. That design is the interesting part. A self-contained binary that carries its own remote worker means you do not have to deploy anything by hand, and the make doctor target checks the prerequisites for it, verifying that Go is in PATH, that zip is in PATH, that go mod verify passes and that the Lambda source file exists. The cost is that the AWS path is not optional in the build. The build script needs zip installed and the Lambda source present, so a contributor on a machine without zip cannot produce a release build without installing it. ## Prometheus metrics, JSON logging and webhooks Three integrations carry the data out of the tool, and the README's feature list names them as Prometheus and Grafana integration with metrics export for visualization and long-term storage, alert notifications with desktop notifications and webhook integration for Slack, Discord and custom endpoints, and multiple output modes. The metrics/ directory in the repository holds the Prometheus exporter, and the dependency list includes the Prometheus protocol buffers generated from buf.build plus protobuf and snappy, which is what the exposition format needs. There is an examples/ directory with a prometheus-grafana/ subdirectory, so the intended deployment is a scrape target plus a Grafana dashboard rather than something you have to assemble yourself. The statistics are computed with caio/go-tdigest/v4, a t-digest implementation for streaming quantiles, which is the right structure for response time percentiles over a long run: it merges incrementally without keeping every sample. The stats/ directory is where that lives. The notification path has two halves. gen2brain/beeep handles desktop notifications on the machine running updo, and the webhook options are --webhook-url and --webhook-header, with the feature list naming Slack, Discord and custom endpoints. The notifications/ directory holds both. The webhook headers flag matters in practice, because Slack and Discord have different payload shapes and an authentication header is how you point the same code at either. The JSON logging mode is the third option and the one that fits a pipeline. With --log the output is structured, so updo --simple --log --count 10 https://example.com > output.json writes a JSON document you can post-process. ## Configuration files exist because CLI flags are global There is a single note in the README that changes how you should use the tool, and it sits directly under the options list. When using CLI flags, all settings apply globally to all monitored targets. Headers, webhook URL, timeouts, all of them. For per-target configuration, you use a TOML configuration file. That is a real constraint, not a documentation oversight. The example in the README shows the flags being used to add an Authorization header and an assertion to a single request, which reads fine with one target. With three targets, the same flag would send the same bearer token to all three and assert the same text on all three, which is wrong in most multi-tenant situations and wrong in most situations where the targets are different applications. The repository has a config/ directory, an example-config.toml at the top level, and the --config flag points at it. The target names in the example, Google and GitHub, are used with --only and --skip, which implies the config file gives each target a name. The command structure is cobra with pflag and viper for configuration loading, and the subcommands include monitor, completion and, judging by the Makefile, a build and deployment workflow. The assets/ and images/ directories hold the TUI assets, widgets/ holds the terminal UI components, and tui/ and simple/ are the two output implementations. For a tool that runs continuously, the config file is the right home for anything per-target, and the CLI is for the things you want to change for one run. ## Packaging, container and what is missing The distribution options are the most complete part of the README, and they cover the platforms a monitoring tool might run on. macOS has a Homebrew tap with brew install owloops/tap/updo, which is marked as the recommended route. Linux has deb, rpm and apk packages downloaded from the releases page with dpkg, rpm and apk, and Arch has an AUR package with yay -S updo or yay -S updo-bin for the binary package, and openSUSE uses zypper with the rpm. Nix has three flavours, running directly with nix run github:Owloops/updo, a temporary shell with nix shell, and system flake integration, and the repository has both flake.nix and flake.lock. Windows is a direct download of the executable via Invoke-WebRequest, plus a manual download option. There is a quick install script for Linux, macOS and Windows under MSYS, and building from source is a clone plus go build, or go install github.com/Owloops/updo@latest. The Dockerfile is a two stage build that produces a very small image. The builder is golang:1.24-alpine with zip and make, it copies the module files first so the dependency layer survives source changes, runs make build-lambda, and then builds the static binary with CGO_ENABLED=0 and stripped symbols. The runtime stage is FROM scratch, with the binary, the CA certificate bundle and nothing else. That is an unusually lean image, and it is what you want for something that runs as a scheduled probe in several regions. The gaps are worth naming. The releases are v0.4.6 in February 2026, v0.4.7 in April and v0.4.8 on 2026-05-26, and the last push was on 2026-05-26, so the project is on a 0.x line with a fairly steady cadence. The README does not describe a configuration file format in detail, does not document the desktop notification requirements per platform, and does not explain what happens when the Lambda invoke fails, which is the failure mode you would hit first in the multi-region path. The tool also has no incident history of its own, since the Prometheus path is described as covering visualization and long-term storage, which means updo is the thing that tells you about a problem and something else that remembers it. ## Conclusion Updo suits someone who wants a status board for a handful of sites on their own machine, or who needs lightweight multi-region probing without running a full monitoring stack, and it is the wrong tool if you need incident management, historical storage, a hosted status page or a supported service. Before adopting it for alerting, read the note about CLI flags applying globally to all targets, because per-target settings require the TOML config file and a shared flag set is a common source of false alerts. Verify first that you have AWS credentials with Lambda invoke permission if you intend to use the multi-region mode, since that path needs IAM, STS and Lambda access. ## FAQ ### What is updo? It is a Go command line tool for monitoring website uptime and performance, with real-time metrics on status, response time and SSL certificate expiry. It can monitor multiple URLs concurrently, output to an interactive TUI, simple text or JSON logs, export Prometheus metrics and send webhook or desktop notifications. ### How do I install updo? The README lists brew install owloops/tap/updo for macOS, deb, rpm and apk packages for Linux, the Arch AUR package, three Nix options including flake integration, a direct Windows download, a quick install script, go install github.com/Owloops/updo@latest, and a Docker build with docker run updo monitor . ### How does updo do multi-region monitoring? The --regions flag takes AWS regions as a comma separated list or the value all, and --profile picks the AWS profile. The tool embeds a Lambda binary compiled for linux/arm64 with the lambda.norpc build tag into its own release binary, and uses the AWS SDK to invoke it, with IAM and STS dependencies for permissioning. ### Can updo send different headers to different targets? Not through CLI flags. The README notes that when using CLI flags all settings apply globally to all monitored targets, so for per-target configuration you need the TOML configuration file passed with --config. The --only and --skip flags then select which named targets run. ### What licence is updo released under? It is MIT licensed, with a LICENSE file at the top of the repository and the licence badge in the README. The last release was v0.4.8 on 2026-05-26 and the last push was on the same date. ## Sources - [Issues](https://github.com/Owloops/updo/issues) - [License: MIT](https://github.com/Owloops/updo/blob/main/LICENSE) - [Owloops/updo on GitHub](https://github.com/Owloops/updo) - [README](https://github.com/Owloops/updo/blob/main/README.md) - [Releases](https://github.com/Owloops/updo/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owloops-updo