# Upcertain > Uptime monitoring for small teams and agencies: HTTP, keyword, ping, port, SSL certificate and heartbeat monitors as often as every 30 seconds, failures confirmed by re-checks before an incident opens, alerts to email, Slack, Discord, Microsoft Teams, Google Chat and signed webhooks, status pages on your own domain, a REST API and an MCP server for AI agents. Upcertain is in early access: billing is not enabled, plans are assigned from the account settings, and prices are shown as "Early access". Checks run from one region (Seoul, AWS ap-northeast-2). It does not offer multi-region checks, browser or synthetic checks, DNS monitors, SMS or phone alerts, or on-call schedules. Plans: - Basic: 10 monitors, checks every 1 min at the fastest, 1 status page, owner only. - Team: 100 monitors, checks every 30 s at the fastest, unlimited status pages, unlimited team members, custom domains, MCP access. - Business: custom limits set per account. ## Product - [Home](https://upcertain.com/): What Upcertain does: six monitor types, confirmed incidents, alert channels, status pages, REST API and MCP. - [Pricing](https://upcertain.com/pricing): Plans and their limits (monitors, fastest interval, status pages, seats) and the plan FAQ. - [Changelog](https://upcertain.com/changelog): Dated list of user-facing changes to Upcertain. - [Upcertain status](https://upcertain.com/s/upcertain): Upcertain's own public status page, an example of the product's status pages. ## Developers - [MCP server docs](https://upcertain.com/mcp): How to connect Claude, Cursor or another MCP client to https://upcertain.com/api/mcp, the tools it offers, example prompts and the REST API. - [Upcertain for AI assistants](https://upcertain.com/ai-info): Factual summary for assistants: capabilities, plans, limits and when Upcertain is the wrong choice. - MCP server endpoint: https://upcertain.com/api/mcp (streamable HTTP; OAuth 2.1 sign-in or an API key; read-only by default). - REST API base: https://upcertain.com/api/v1 (account, monitors, incidents, maintenance, status pages; bearer API keys created by owners and admins). - [Full text for assistants](https://upcertain.com/llms-full.txt): this summary, the answers to common questions and the full text of every guide and doc. ## Features - [Features](https://upcertain.com/features): What Upcertain monitors and how: HTTP, keyword, ping, port, SSL and heartbeat checks, confirmed incidents, alerts and status pages on your domain. - [Status pages on your own domain](https://upcertain.com/features/status-pages): Public, private or password-protected status pages that update from your monitors, show each service's downtime and run on your own domain. - [Website and API uptime monitoring](https://upcertain.com/features/uptime-monitoring): Check websites and APIs as often as every 30 seconds with HTTP and keyword monitors, re-check before an incident opens, and alert the team that owns it. - [Heartbeat monitoring for cron jobs and workers](https://upcertain.com/features/heartbeat-monitoring): Know when a cron job, queue worker or backup stops running. Your job calls a unique URL on schedule; Upcertain alerts when the calls stop arriving. - [Incidents: one record from first failure to recovery](https://upcertain.com/features/incidents): Every confirmed outage becomes an incident with its cause, the failed request, a timeline, acknowledgement, team notes and status page updates. - [Keyword monitoring for pages that fail quietly](https://upcertain.com/features/keyword-monitoring): Catch pages that return 200 but show an error, an empty list or a maintenance notice: keyword monitors check that a phrase is, or is not, on the page. - [Ping and port monitoring for servers and services](https://upcertain.com/features/ping-and-port-monitoring): Watch servers, mail servers, databases and game servers with ping and TCP port monitors, with a TCP fallback when ICMP is blocked by a firewall. - [SSL certificate monitoring and expiry alerts](https://upcertain.com/features/ssl-monitoring): Get warned before a TLS certificate expires and alerted when one is invalid: expiry, hostname and chain checks, with warnings on the days you choose. ## Alert channels - [Alert channels](https://upcertain.com/channels): Send Upcertain downtime, recovery and SSL alerts to email, Slack, Discord, Microsoft Teams, Google Chat or your own signed webhooks. - [Slack uptime alerts](https://upcertain.com/channels/slack): Post Upcertain down, recovery and SSL alerts to a Slack channel through an incoming webhook, with acknowledge and incident links in each message. - [Discord downtime alerts](https://upcertain.com/channels/discord): Get Upcertain uptime, recovery and SSL expiry alerts in a Discord channel through a channel webhook. Useful for small teams and communities. - [Email downtime alerts](https://upcertain.com/channels/email): Upcertain email alerts: one message per recipient with a personal stop link, acknowledge buttons for people who can act, and weekly or monthly reports. - [Google Chat uptime alerts](https://upcertain.com/channels/google-chat): Send Upcertain down, recovery and SSL expiry alerts into a Google Chat space with an incoming webhook, set up in a couple of minutes. - [Microsoft Teams uptime alerts](https://upcertain.com/channels/microsoft-teams): Post Upcertain downtime, recovery and SSL alerts to a Microsoft Teams channel through a Workflows webhook, with links to acknowledge each incident. - [Signed webhooks for down, recovery and SSL events](https://upcertain.com/channels/webhooks): Receive Upcertain alerts as signed JSON in your own system: event types, the payload, the headers and how to verify the HMAC-SHA256 signature. ## Documentation - [Documentation](https://upcertain.com/docs): How to set up Upcertain: heartbeat monitors, status pages on a custom domain, password protection, and connecting AI agents over MCP. - [Put a status page on your own domain](https://upcertain.com/docs/status-pages/custom-domain): Serve an Upcertain status page at status.yourcompany.com: add the CNAME, verify it, and get an HTTPS certificate issued automatically. - [Set up a heartbeat monitor for a cron job](https://upcertain.com/docs/monitors/heartbeat): Create a heartbeat monitor and call its URL from cron, Node.js, Python, PHP, Laravel or GitHub Actions, so you hear when a scheduled job stops. - [Add a status badge to your README or website](https://upcertain.com/docs/status-pages/badge): Show a status page's live state as a small badge in a GitHub README, documentation or your website, with copy-ready Markdown, HTML and embed code. - [Connect Upcertain to Claude](https://upcertain.com/docs/mcp/claude): Add Upcertain as a custom connector in Claude on the web or desktop, sign in, choose read-only or read-write, and ask Claude about monitors and incidents. - [Email subscribers on a status page](https://upcertain.com/docs/status-pages/subscribers): Let visitors subscribe to a status page by email, confirm with one button, and receive every announcement you publish with a one-click unsubscribe. - [HTTP monitors: options and status codes](https://upcertain.com/docs/monitors/http): Every option of an Upcertain HTTP monitor: method, headers, body, authentication, expected status codes, timeout, redirects and certificate checks. - [Import monitors from a CSV file](https://upcertain.com/docs/monitors/import-csv): Create many monitors at once from a CSV file or a list of URLs: the columns Upcertain reads, the preview, plan limits and how groups are created. - [Keyword monitors: check what a page says](https://upcertain.com/docs/monitors/keyword): Set up a keyword monitor that fails when a word is missing from a page, or when an error message appears, with case-sensitive matching if you need it. - [Password-protected and private status pages](https://upcertain.com/docs/status-pages/password-protection): Share a status page with customers or staff only: protect it with a password, or make it private to signed-in members of your account. - [Ping monitors: check that a host is reachable](https://upcertain.com/docs/monitors/ping): How Upcertain's ping monitor checks a server with ICMP, falls back to TCP on ports 443 and 80, and when to use a port or HTTP monitor instead. - [Port monitors: check a TCP service](https://upcertain.com/docs/monitors/port): Monitor any TCP service, such as SMTP, PostgreSQL, Redis or SSH, by opening a connection to its port on a schedule and alerting when it stops answering. - [REST API reference](https://upcertain.com/docs/api): Upcertain's REST API: authentication with API keys, endpoints for monitors, uptime, incidents, maintenance and status pages, errors and rate limits. - [Schedule maintenance windows](https://upcertain.com/docs/status-pages/maintenance): Schedule one-off or recurring maintenance so planned work does not alert anyone or count against uptime, and show it on your status pages ahead of time. - [SSL certificate monitors and expiry warnings](https://upcertain.com/docs/monitors/ssl): Set up an SSL certificate monitor, choose the days you are warned before expiry, and route the warnings to the person who renews certificates. - [Team roles and the audit log](https://upcertain.com/docs/team-roles): What owners, admins, editors, viewers and notify-only contacts can do in Upcertain, how invitations work, and what the audit log records. - [Use Upcertain from Claude Code](https://upcertain.com/docs/mcp/claude-code): Add Upcertain's MCP server to Claude Code with one command, sign in from the terminal, and check monitors and incidents while you work. - [Use Upcertain in Cursor](https://upcertain.com/docs/mcp/cursor): Connect Cursor to Upcertain's MCP server through mcp.json, sign in or use an API key, and ask about monitors and incidents from the editor. - [Working with incidents](https://upcertain.com/docs/incidents): How incidents open and resolve in Upcertain, how to acknowledge one, add notes, post a status update, read the failed request, and export history as CSV. ## Uptime monitoring guides - [Uptime monitoring guides](https://upcertain.com/learn): Plain guides to uptime monitoring: confirmation checks, check intervals, false alarms during deploys, heartbeat monitoring and what 99.9% uptime allows. - [Confirmation checks: how to stop false downtime alerts](https://upcertain.com/learn/confirmation-checks): Why one failed check should not wake anyone, how re-checks before an incident work, and how to choose the number of checks and the time between them. - [Cron job monitoring: catching jobs that silently stop](https://upcertain.com/learn/cron-job-monitoring): Why cron jobs fail without anyone noticing, the ways to monitor them, and how heartbeat monitoring alerts you when a scheduled job does not run. - [Dead man's switch monitoring for scheduled jobs](https://upcertain.com/learn/dead-mans-switch-monitoring): How dead man's switch (heartbeat) monitoring catches cron jobs, backups and workers that silently stop, and how to choose the period and grace time. - [Downtime alerts during deploys: why they happen and how to stop them](https://upcertain.com/learn/deploy-false-alarms): Rolling restarts and deploys often return 502 or 503 for a minute. How to stop those responses from paging your team without missing real outages. - [How often should you check uptime? 30 seconds, 1 minute or 5 minutes](https://upcertain.com/learn/check-interval): What a 30-second, 1-minute or 5-minute check interval means for how fast you hear about an outage and which short outages you miss entirely. - [How to check if a website is down, for everyone or just you](https://upcertain.com/learn/how-to-check-if-a-website-is-down): Quick ways to tell whether a website is down for everyone or only for you, with the commands to run, and why a one-off check is not monitoring. - [How to create a status page customers will trust](https://upcertain.com/learn/how-to-create-a-status-page): A practical guide to building a status page: what to show, how to name services, where to host it, how to write updates, and what to do during an outage. - [How to monitor website uptime, step by step](https://upcertain.com/learn/how-to-monitor-website-uptime): A step-by-step setup for website uptime monitoring: what to check, how often, how to avoid false alarms, where alerts go, and how to tell customers. - [How to monitor your MCP server's uptime](https://upcertain.com/learn/monitor-mcp-server-uptime): Your MCP server is now part of your product. How to monitor a remote MCP endpoint, why to expect a 401, and what to watch besides the endpoint itself. - [Incident response for small teams](https://upcertain.com/learn/incident-response-small-teams): A lightweight incident process for teams without an on-call rotation: who responds, how to acknowledge, what to tell customers and how to learn from it. - [Monitoring from one region: what checks from Seoul mean for you](https://upcertain.com/learn/monitoring-from-seoul): Upcertain checks from Seoul. What single-region monitoring catches, what it can miss, how distance affects response times, and when it suits Asia-Pacific teams. - [SSL certificate expiry: why it still causes outages](https://upcertain.com/learn/ssl-expiry-monitoring): Automated renewal did not end expired-certificate outages. Why renewals fail, how far ahead to be warned, and what to check besides the expiry date. - [Uptime monitoring pricing compared: what you pay for](https://upcertain.com/learn/uptime-monitoring-pricing-compared): How uptime monitoring tools price their plans: per monitor, per seat, per site or by tier, with entry plans and add-ons from their own pricing pages. - [What 99.9% uptime means in minutes](https://upcertain.com/learn/what-does-99-9-uptime-mean): 99.9% uptime allows 43 minutes of downtime a month and about 8 hours 46 minutes a year. A table for 99% to 99.999%, and what the numbers leave out. - [What is uptime monitoring?](https://upcertain.com/learn/what-is-uptime-monitoring): Uptime monitoring checks your websites, APIs and servers on a schedule and alerts you when they stop working. How it works, what it catches and what it misses. ## Upcertain compared - [Upcertain compared](https://upcertain.com/compare): Factual comparisons of Upcertain with other uptime monitoring and status page tools, with the sources each fact was read from. - [Upcertain and Better Stack compared](https://upcertain.com/compare/better-stack): How Upcertain compares with Better Stack for uptime monitoring and status pages: what each includes, where Better Stack does more, and who each suits. - [Upcertain and UptimeRobot compared](https://upcertain.com/compare/uptimerobot): How Upcertain compares with UptimeRobot on check intervals, seats, status pages, alerts and AI access, with UptimeRobot's figures from its pricing page. - [Freshping has shut down: moving your monitors](https://upcertain.com/compare/freshping): Freshworks retired Freshping in March 2026. How to rebuild your monitors, alerts and status page elsewhere, with a CSV import into Upcertain. - [Upcertain and Atlassian Statuspage compared](https://upcertain.com/compare/statuspage): Atlassian Statuspage is a status communication tool priced by subscribers and team members. How it compares with Upcertain's monitoring-driven status pages. - [Upcertain and Cronitor compared](https://upcertain.com/compare/cronitor): Cronitor prices per monitor and per user, with cron monitoring at its core. How it compares with Upcertain's heartbeat and uptime monitoring. - [Upcertain and Dead Man's Snitch compared](https://upcertain.com/compare/dead-mans-snitch): Dead Man's Snitch watches cron jobs with "snitches" on simple plans. How it compares with Upcertain's heartbeats, uptime checks and status pages. - [Upcertain and Healthchecks.io compared](https://upcertain.com/compare/healthchecks-io): Healthchecks.io is a focused cron job monitor with a generous free tier. How it compares with Upcertain, which pairs heartbeats with uptime checks. - [Upcertain and HetrixTools compared](https://upcertain.com/compare/hetrixtools): HetrixTools offers uptime and blacklist monitoring with a free tier and checks from 12 locations. How it compares with Upcertain. - [Upcertain and Hyperping compared](https://upcertain.com/compare/hyperping): Upcertain and Hyperping side by side: monitors, seats, status pages, on-call and browser checks, with Hyperping's figures from its pricing page. - [Upcertain and Instatus compared](https://upcertain.com/compare/instatus): Instatus starts from the status page; Upcertain starts from monitoring. How they compare on monitors, checks, subscribers, domains and team members. - [Upcertain and Oh Dear compared](https://upcertain.com/compare/oh-dear): Oh Dear prices by the number of sites with every feature on every plan. How it compares with Upcertain on checks, verification, status pages and pricing. - [Upcertain and OpenStatus compared](https://upcertain.com/compare/openstatus): OpenStatus offers status pages and multi-region uptime monitoring with a free plan. How it compares with Upcertain on checks, regions, pages and plans. - [Upcertain and Pingdom compared](https://upcertain.com/compare/pingdom): Pingdom, part of SolarWinds, offers uptime, transaction and real user monitoring for larger sites. How it compares with Upcertain for smaller teams. - [Upcertain and Pulsetic compared](https://upcertain.com/compare/pulsetic): Pulsetic offers uptime, cron and status page monitoring with regional checks and a free plan. How its plans compare with Upcertain's. - [Upcertain and Site24x7 compared](https://upcertain.com/compare/site24x7): Site24x7 is a full monitoring suite from Zoho with a free plan and trial. How its website monitoring compares with Upcertain's focused uptime service. - [Upcertain and StatusCake compared](https://upcertain.com/compare/statuscake): Upcertain and StatusCake side by side: monitors and intervals per plan, team members, page speed and domain checks, alert channels and status pages. - [Upcertain and Uptime.com compared](https://upcertain.com/compare/uptime-com): Uptime.com covers many check types from a global probe network. How it compares with Upcertain on checks, locations, alerts, users and status pages. - [Upptime or a hosted monitor: how to choose](https://upcertain.com/compare/upptime): Upptime runs uptime checks and a status page on GitHub Actions, Issues and Pages. When that is enough, and when a hosted monitor fits better. - [Uptime Kuma or a hosted monitor: how to choose](https://upcertain.com/compare/uptime-kuma): Uptime Kuma is a capable self-hosted monitor. What running it yourself involves, where it does more than Upcertain, and when hosted monitoring fits better. ## Upcertain for your kind of team - [Upcertain for your kind of team](https://upcertain.com/for): How agencies, SaaS teams and makers of side projects use Upcertain: what to monitor, how to route alerts and how to run a status page. - [Uptime monitoring for agencies](https://upcertain.com/for/agencies): Monitor every client's sites in one place, alert the right people per client, and give each client a status page of their own on their domain. - [Uptime monitoring for SaaS teams](https://upcertain.com/for/saas): Monitor the app, API, sign-in and background jobs of a SaaS product, alert the team that owns each service, and keep customers informed on a status page. - [Uptime monitoring for Shopify stores](https://upcertain.com/for/shopify): Shopify runs the platform, but your theme, apps and integrations can still break the store. What to monitor and how to hear about it first. - [Uptime monitoring for side projects](https://upcertain.com/for/side-projects): Keep an eye on a side project without a pager: check the site and its jobs, get alerts where you already are, and show a status page to your users. - [Uptime monitoring for WordPress sites, without a plugin](https://upcertain.com/for/wordpress): Monitor a WordPress site from outside: catch the critical error page, plugin breakage, an expired certificate and WP-Cron that stopped running. - [Website monitoring for small businesses](https://upcertain.com/for/small-business): Know when your business website, booking form or online shop stops working, without being technical: what to monitor, who should hear, and what to do. ## Blog - [Blog](https://upcertain.com/blog): Notes from the team that builds Upcertain: how we decide a site is down, what we show on status pages, and connecting AI agents to monitoring. - [How Upcertain decides a site is down](https://upcertain.com/blog/how-we-decide-a-site-is-down): From a failed request to an alert in Slack: the checks, re-checks and rules Upcertain uses before it calls something an outage, and why. - [Brief outages on status pages: why we fold them and show each service's downtime](https://upcertain.com/blog/brief-outages-on-status-pages): Why Upcertain status pages group simultaneous incidents, show each service's own downtime and fold short blips into one line a day without hiding them. - [Ask Claude what's down: connecting your uptime monitors over MCP](https://upcertain.com/blog/ask-claude-whats-down): Connect Upcertain's MCP server to Claude and Claude Code, then ask about outages, uptime and incidents in plain language. Setup, prompts and safeguards. - [Freshping shut down in 2026. What to look for in the next monitor](https://upcertain.com/blog/freshping-shutdown-what-next): Freshping's free monitoring ended in March 2026. A checklist for choosing what comes next, from check intervals to status pages, and how to move quickly. - [Monitoring a Next.js app on Vercel: health route, keyword check and cron heartbeats](https://upcertain.com/blog/monitor-nextjs-on-vercel): A worked setup for a Next.js app on Vercel: a health route that checks the database, keyword and SSL monitoring, and heartbeats for Vercel cron jobs. - [Monitoring a Supabase-backed app: what to check and how](https://upcertain.com/blog/monitor-supabase-app): How to monitor an app built on Supabase: a health check through your own API, a port check on the connection pooler and heartbeats sent from pg_cron. - [Heartbeats for systemd timers, Kubernetes CronJobs and queue workers](https://upcertain.com/blog/heartbeats-for-systemd-kubernetes-and-workers): Patterns for adding heartbeat monitoring to systemd timers, Kubernetes CronJobs, Windows Task Scheduler and long-running queue workers. - [Slack alert fatigue: how to keep an alert channel worth reading](https://upcertain.com/blog/slack-alert-fatigue): Why alert channels turn into noise and the settings that fix it: confirmation, one message per incident, recovery in place, routing by owner and grouping. - [An error budget for small teams: spending your 43 minutes a month](https://upcertain.com/blog/error-budget-for-small-teams): Turn an uptime target into a monthly downtime budget, see what deploys, incidents and maintenance spend from it, and decide when to slow down. - [Incident communication templates for small teams](https://upcertain.com/blog/incident-communication-templates): Copy-ready status page updates for investigating, identified, monitoring and resolved incidents, plus maintenance notices and a short post-incident note. - [Status 200, still broken: catching silent failures with keyword checks](https://upcertain.com/blog/keyword-monitoring-silent-failures): Pages that return 200 while broken are the outages status-code checks miss. Common patterns, the keyword to use for each, and how to keep the checks honest. ## Tools - [Uptime and downtime calculator](https://upcertain.com/tools/uptime-calculator): Calculator: uptime percentage to allowed downtime per period, and downtime back to uptime. ## Optional - [Contact](https://upcertain.com/contact): Contact form for Business plans, onboarding and support. - [Privacy policy](https://upcertain.com/privacy): What Upcertain collects, where it is stored (Seoul) and for how long. - [Terms of service](https://upcertain.com/terms): Terms of service during early access. - Support: upcertain-support@innovation-insight.com ## Questions about the product ### What can Upcertain check? Websites and APIs over HTTP(S), pages that must contain a keyword, hosts by ping, open TCP ports and SSL certificates. Heartbeat monitors work the other way round: your cron job or worker calls a URL, and Upcertain alerts when the calls stop arriving. ### How does it avoid false alarms? When a check fails, Upcertain re-checks before opening an incident, so a single dropped request does not alert anyone. You can set how many failed checks in a row are needed per monitor. ### Where do alerts go? Email, Slack (through an incoming webhook), Discord, Microsoft Teams, Google Chat and your own webhooks. Each monitor can alert different channels, and each email recipient gets a personal link to stop alerts. ### Can a status page use our own domain? Yes, on plans that include custom domains. Point a CNAME record at Upcertain and the HTTPS certificate is issued automatically. Pages can be public, private or password-protected. ### Can AI agents use Upcertain? Yes. The MCP server lets Claude, Cursor or your own agent list monitors, read uptime and incidents, create monitors and acknowledge incidents with an account API key. The MCP docs are at https://upcertain.com/mcp. ### How much does it cost? Upcertain is in early access. Billing is not enabled yet, so plans are assigned from your account settings. We will announce prices before any billing starts, and nothing is charged without your agreement. ## Questions about plans ### How much does it cost? Upcertain is in early access. Billing is not enabled yet, so plans are assigned from your account settings. We will announce prices before any billing starts, and nothing is charged without your agreement. ### Can I change plans later? Yes. Owners and admins switch between Basic and Team any time from Settings, Plan & usage. Before the change applies we show exactly what happens: on a downgrade, monitors over the limit are paused (oldest first) and faster intervals are raised to the plan's minimum; upgrading again restores the intervals. ### What counts as a monitor? Each URL, keyword, ping, port, SSL or heartbeat check you create is one monitor. Paused monitors do not count toward the active limit. ### How is a failure confirmed? When a check fails, Upcertain re-checks before opening an incident, so a single dropped request does not alert anyone. You can set how many failed checks in a row are needed per monitor. ### What is in Business? Business is for agencies and platforms that need more monitors, faster intervals or other custom limits. Tell us what you need and we set the limits on your account. ### Where is my data stored? Account data is stored in a Supabase Postgres database in the Seoul (ap-northeast-2) region, with every account separated by row-level security. See the privacy policy for details. ## Full text of guides and docs ## Website and API uptime monitoring Source: https://upcertain.com/features/uptime-monitoring Upcertain requests your URLs on the schedule you set, checks the status code and, if you want, the page content, and only opens an incident once a failure is confirmed. ### What an HTTP check does Each check sends a request to your URL and compares the answer with what you expect. By default any status from 200 to 399 counts as up. You can name exact codes or ranges instead, such as 200, 2xx or 200-299, 301, so an API that should never redirect fails when it does. - Methods, headers and body. GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS, up to 30 request headers and a body of up to 64 KB, so you can call a health endpoint the way your clients do. - Basic authentication for pages behind a username and password. - Timeout from 1 to 60 seconds (30 by default). A slow answer counts as a failure once it passes the timeout. - Redirects are followed by default; turn that off to check the redirect itself. - Certificate checks come with every HTTPS monitor: an expired certificate, a hostname mismatch or a broken chain fails the check, and you are warned 30, 14 and 7 days before expiry unless you pick other days. ### Keyword checks for pages that fail politely Some failures still return 200: a maintenance page, an empty product list, a framework error rendered as HTML. A keyword monitor passes only when a word or phrase is present on the page, or only when it is absent, with an option for case-sensitive matching. ### How often to check Intervals run from 30 seconds to 24 hours: 30 s, 60 s, 5 min, 30 min, 1 h, 12 h and 24 h. The Basic plan checks as often as every 60 seconds; Team and Business as often as every 30 seconds. Which interval to pick depends on how fast you need to know and how much noise you will tolerate. ### Confirmed before anyone is alerted A single failed request is often a dropped packet or a deploy restarting a container. When a check fails, Upcertain re-checks before opening an incident: from 0 to 5 confirmation checks, 15, 30, 60 or 120 seconds apart. New monitors start with one confirmation check after 15 seconds. The trade-off is explained in confirmation checks. ### What happens when it is down 1. The incident opens with the cause: the status code, a timeout, a missing keyword, a DNS failure or a refused connection. 2. Each alert channel on the monitor is notified, after the delay you set for that channel (0 to 1440 minutes). 3. Reminders repeat while it stays down if you ask for them, every 5 to 1440 minutes. 4. Someone acknowledges the incident to stop the reminders. 5. When the check passes again the incident resolves and every channel gets the recovery, with the downtime. Alerts go to email, Slack, Discord, Microsoft Teams, Google Chat or a signed webhook. The outage also shows on your status page if the monitor is on one. ### Adding many sites at once Guided setup turns one site into several monitors (the home page, a keyword check, the certificate) in one step. CSV import takes a file with header columns or one URL per line, shows a preview of every row and creates up to 200 monitors at a time. Monitors beyond your plan's limit are created paused rather than refused. ### What it does not do Checks run from one region, Seoul (AWS ap-northeast-2); what that means. Upcertain does not run browser or multi-step transaction checks, multi-region checks, DNS record monitors or phone and SMS alerts. If you need those, pick a tool that has them; if you need fast, confirmed HTTP checks with clear alerts and a status page, this is what Upcertain is built for. #### Does an HTTP monitor also watch the SSL certificate? Yes. Every HTTPS monitor fails on an expired certificate, a hostname mismatch or an invalid chain, and warns before expiry (30, 14 and 7 days by default). A separate SSL monitor is for hosts you only want to watch for the certificate. #### Can I monitor an API that needs a token? Yes. Add the token as a request header, for example Authorization: Bearer .... Header values are stored with the monitor and sent with every check. #### Where do the checks come from? From Upcertain's servers in Seoul. Requests carry the user agent Upcertain-Monitor/1.0 (+https://upcertain.com), so you can recognise them in your logs or allow them through a firewall rule. ## Status pages on your own domain Source: https://upcertain.com/features/status-pages A status page answers "is it down?" before your customers have to ask. Upcertain builds it from the monitors you already have and keeps it current on its own. ### Built from your monitors Pick the monitors to show and group them into sections, such as Platform and Apps. Give each one a public name ("Web app" rather than prod-web-2) and hide the URLs if they reveal internal hosts. The page shows the current state of every service and 90 days of uptime. ### Your domain, your look - Custom domain. Point a CNAME such as status.example.com at pages.upcertain.com; Upcertain verifies it and the HTTPS certificate is issued automatically. See custom domains. Included on Team and Business. - Logo and theme. Upload your logo and choose a light or dark page. - Address on Upcertain. Every page also has an address at upcertain.com/s/. ### Honest about outages, without the noise The page lists the last 7 days of incidents, grouped by day in the page's time zone. Incidents that start within 2 minutes of each other show as one: "Web app, API and 8 more were unavailable". Each shows the cause, the time range and each service's own downtime, because services on different check cycles fail and recover a few seconds apart. Short blips are folded into one line per day ("6 brief outages, each under 5 minutes, 7 m 30 s in total"). You choose what counts as brief, from 1 to 30 minutes, or leave brief outages off the list entirely; the page then says how many were not listed, and uptime still counts them. Why we built it this way is in brief outages on status pages. ### History and maintenance A history page shows 90 days of incidents a month at a time. Scheduled maintenance appears in its own section ahead of time, and time inside a maintenance window counts as maintenance, not downtime. ### Who can see it - Public: anyone with the address, and search engines. - Password-protected: visitors enter a password once per browser. See password protection. - Private: only signed-in members of your account. ### Subscribers Visitors can subscribe by email. They confirm with a button press, and every announcement you publish reaches them with an unsubscribe link that also works as one-click unsubscribe in mail clients. ### Plans Basic includes one status page. Team and Business include unlimited pages, custom domains and the option to hide the small "Powered by Upcertain" footer link. Every page also offers a status badge, a small image of its current state for a README or your website. See pricing. #### Can I see a live example? Yes: Upcertain's own status page runs on the product. #### Do brief outages still count against uptime? Yes. Folding or hiding brief outages changes only how the incident list reads. The uptime figures include every minute a monitor was down. #### What does a custom domain serve? Only the status page and its history. The app, API and MCP server answer on upcertain.com only. ## Heartbeat monitoring for cron jobs and workers Source: https://upcertain.com/features/heartbeat-monitoring Scheduled jobs fail silently: nothing errors, nothing logs, the job simply does not run. A heartbeat monitor turns that silence into an alert. ### How it works 1. Create a heartbeat monitor and tell it how often the job runs, from every 30 seconds to every 30 days. 2. Add a grace period for jobs whose run time varies, up to one day (60 seconds by default). 3. Copy the monitor's unique URL and call it at the end of each successful run, with GET, POST or HEAD. 4. If no call arrives within the period plus the grace period, Upcertain opens an incident and alerts your channels. The next call resolves it. # crontab: back up every night at 02:00, then report in 0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://upcertain.com/api/heartbeat/ Calling the URL only after the job succeeds (&& in the example) means a job that runs but fails also stops the heartbeats. Examples for Node.js, Python, PHP and GitHub Actions are in the heartbeat setup guide. ### What it catches - A crontab entry lost in a server rebuild. - A queue worker that crashed and was never restarted. - A backup script that now fails on a full disk. - A scheduled function your platform silently stopped running. ### Details that matter - Starting clean. Until the first call arrives, the period counts from when you created the monitor. Resuming a paused monitor starts the clock again, so a job paused for a week does not alert the moment you resume it. - Repeated calls are cheap. Calls for one monitor inside 5 seconds share one answer, and each sending address may make 30 calls in a burst, then one a second. - The URL is the secret. Anyone with it can report in, so keep it out of public repositories. If it leaks, create a new heartbeat monitor, which gets a new URL, and delete the old one. - Same alerts as every monitor. Heartbeat incidents go to the same channels, with the same acknowledge and recovery messages. They have no confirmation checks: a missed deadline is already confirmed. ### Why it is called a dead man's switch The pattern is older than software: the alarm sounds unless someone keeps pressing the switch. Dead man's switch monitoring explains when to use it and how to pick the period and grace. #### Does the heartbeat URL accept data? It records that the call arrived and from which address. A body is ignored, so send whatever your HTTP client sends by default. #### Can I use it for jobs that run every few seconds? The shortest period is 30 seconds. For anything faster, call the URL from the worker's own loop at most once every 30 seconds. ## SSL certificate monitoring and expiry alerts Source: https://upcertain.com/features/ssl-monitoring An expired certificate takes a site down as surely as a crashed server, and browsers show visitors a warning page instead of your product. Upcertain watches certificates so renewals never come as a surprise. ### What is checked - Expiry. How many days the certificate has left. - Hostname. The certificate must cover the name you monitor. - Chain. The certificate must chain to a trusted root, with every intermediate served. An expired certificate, a hostname mismatch or a broken chain fails the check and opens an incident like any other outage, with the reason in the alert. ### Warnings before expiry Warnings arrive 30, 14 and 7 days before expiry by default. You can pick up to five days between 1 and 90, for example 45, 21 and 3 if your renewals go through a slow approval. Each warning names the host, the expiry date and the issuer, and goes to the channels that subscribe to SSL events. Monitor | What fails it | Expiry warnings HTTPS website or API | The page itself, plus an invalid certificate | Yes SSL certificate | Only the certificate | Yes Every HTTPS website monitor already does both. Use a separate SSL monitor for hosts you do not want to watch for uptime, or where you want certificate warnings to go to a different channel than outages. ### Why automated renewals still fail Certificates from Let's Encrypt and other automated issuers renew on their own until something changes. A DNS record moves, or a firewall blocks the validation request. A load balancer keeps serving the old certificate after the new one is issued, or a host behind a CDN is forgotten. An expiry warning 30 days out turns each of those into a calm fix instead of an outage. More in why certificate expiry still causes outages. ### Alert routing Each alert channel chooses which events it receives: down, recovery and SSL. A common setup sends outages to the on-duty Slack channel and SSL warnings to the email address of whoever manages certificates. #### Does it check certificates on ports other than 443? An HTTPS monitor checks the certificate of the URL it requests, including a non-standard port in the URL. #### Will I get the same warning every day? No. Each warning day you choose sends one warning per certificate. ## Keyword monitoring for pages that fail quietly Source: https://upcertain.com/features/keyword-monitoring A status code tells you the server answered. It does not tell you the page works. Keyword monitoring reads the answer too. ### The failures status codes miss - A framework renders its error page with status 200. - A CDN serves a cached copy of a maintenance page. - The product list loads but is empty because the search index is down. - A login page renders, but the form posts to a broken endpoint, so the success text never appears. - A health endpoint answers 200 with "database":"down" inside. ### How it works A keyword monitor requests the URL like an HTTP monitor and then searches the response for a word or phrase of up to 500 characters. Must contain fails when the phrase is missing; must not contain fails when it appears. Matching ignores case unless you turn case-sensitive matching on. The first 1 MB of the response is searched. ### Good keywords Page | Mode | Keyword Shop category | Must contain | Add to basket Checkout | Must contain | Order summary Any page | Must not contain | Something went wrong JSON health check | Must contain | "status":"ok" Status of a dependency | Must not contain | "database":"down" Pick text that appears only when the page works. Your company name is a poor keyword: it is on the error page too. ### Alerts that say why When a keyword check fails, the incident and every alert name the cause, Keyword missing or Keyword present, so whoever picks it up knows the server answered and the content is wrong. Keyword monitors have the same intervals, confirmation checks and alert channels as every other monitor. ### Limits to know The search reads the HTML the server sends, before any JavaScript runs. For pages rendered in the browser, monitor a server-rendered page or an API response that carries the same information. Upcertain does not run a browser. #### Can a keyword monitor check JSON? Yes. The response body is searched as text, so a keyword such as "status":"ok" works on a JSON health endpoint. Include the quotes so the match is exact. #### Does the keyword have to match the whole page? No. The phrase only has to appear somewhere in the first 1 MB of the response, or be absent from it in must-not-contain mode. #### Does a keyword failure still check the status code? Yes. Both must pass. A page with the right text and a 500 status is down, and so is a 200 page without the text. ## Ping and port monitoring for servers and services Source: https://upcertain.com/features/ping-and-port-monitoring Not everything worth monitoring has a web page. Ping monitors check that a host is reachable; port monitors check that a service on it answers. ### Ping: is the host there? A ping monitor sends one ICMP echo request. If nothing answers, perhaps because a firewall drops ICMP, it tries a TCP connection on port 443 and then 80. A reply, a connection, or even a refused connection counts as up: the host answered. Only silence on all of them is down. You can also choose TCP-only mode. Details are in the ping monitor docs. ### Port: does the service answer? A port monitor opens a TCP connection to a host and port, from 1 to 65535, and is up when the connection opens within the timeout. Use it for SMTP on 587, IMAP on 993, PostgreSQL on 5432, Redis on 6379, SSH on 22, or a game server's own port. See the port monitor docs. ### Which to use Question | Monitor Is the server online at all? | Ping Is the mail server accepting connections? | Port 587 or 25 Is the database reachable from the internet? | Port, only if it is meant to be public Is the website working? | HTTP or keyword, not ping Did the nightly job run? | Heartbeat ### What each failure says - Connection refused: the host is up, nothing listens on the port. - TCP timeout: no answer at all. - Timeout: no ICMP reply and no TCP answer on 443 or 80. - DNS failure: the hostname did not resolve. ### Same incidents and alerts Ping and port monitors use the same intervals (30 s to 24 h), confirmation checks, alert channels and status pages as HTTP monitors. A server and its services can sit in one group and one status page section. ### Private networks Upcertain checks from the internet and refuses private addresses. For a host on a private network, run a small job inside the network that checks it and calls a heartbeat URL; the heartbeat alerts when the job stops reporting. #### Why does a refused connection count as up for ping? A refusal is an answer from the host, which proves it is online and reachable. Port monitors are stricter: for them a refused connection is down, because the service should be listening. #### Can I monitor UDP services? No. Port monitors open TCP connections only. ## Incidents: one record from first failure to recovery Source: https://upcertain.com/features/incidents An alert says something is wrong. An incident is where the team works it out: what failed, since when, who is on it and what customers were told. ### Opened only when a failure is confirmed An incident opens after the monitor's confirmation checks all fail. Its start time is the first failed check, so the recorded downtime matches what users saw. It resolves on its own with the first passing check. ### What an incident shows - Cause: the status code, timeout, missing keyword, DNS failure, refused connection, certificate problem or missed heartbeat. - The failed request and response: method, URL and headers sent, and the status, headers and the start of the body received. - Timeline: detected, confirmed, alerts sent, acknowledged, comments, recovery. - Duration, in the format the whole app uses: 9 m 19 s. ### Acknowledge to stop the noise Alerts link straight to the incident. Acknowledging it records who took it and stops repeat reminders on every channel. Owners, admins and editors can acknowledge; email alerts show the button only to people who can use it. ### Notes and public updates Team members add notes to the timeline: what they found, what they changed, who is on it. When customers need to know, post a status update from the incident to the status pages it affects; subscribers receive it by email. ### Fewer, clearer alerts - Alert grouping: when several monitors fail within a few minutes, owners and admins can have them arrive as one alert listing them all. - Delays and reminders per monitor and channel: immediate in Slack, five minutes later by email, a reminder every 30 minutes until someone acknowledges. - Maintenance windows keep planned work from opening incidents at all. ### History and export Search incidents by monitor, filter them by status or tag, sort them, and export them as CSV with the cause, status code, start, resolution, duration and who acknowledged each one. The REST API and the MCP server return the same records. #### Who receives the alert for an incident? The alert channels attached to the monitor, each after its own delay. Email alerts go to each recipient separately; see email alerts. #### Can an incident be reopened? No. If a monitor fails again after recovering, a new incident opens, so each outage keeps its own record and duration. ## Slack uptime alerts Source: https://upcertain.com/channels/slack Send each monitor's alerts to the Slack channel of the team that owns the service. Setup takes an incoming webhook URL and two minutes. ### Create the incoming webhook in Slack 1. In Slack, open Apps and add Incoming Webhooks (or open your own Slack app's Incoming Webhooks page and turn it on). 2. Choose the channel the alerts should go to, for example #ops-alerts. 3. Copy the webhook URL. It starts with https://hooks.slack.com/services/. Slack fixes the channel when the webhook is created. To alert a second channel, create a second webhook and add it as a second Upcertain channel. ### Add it in Upcertain 1. In Upcertain, open Settings, Alert channels and choose Slack. Owners, admins and editors can add channels. 2. Paste the webhook URL. Add the channel name (#ops-alerts) as a label so your team can tell channels apart; Slack decides the actual channel. 3. Pick the events to send: Down, Up (recovery) and SSL certificate expiry. 4. Tick Pre-select on new monitors if this should be the default for monitors you create from now on. Existing monitors keep their own choice. 5. Save, then use Send a test in the channel list to post a test message. 6. Open each monitor that should alert here and add the channel under its alert settings, with an optional delay and repeat interval. ### What a Slack alert looks like - Down: the monitor's name and address, the cause (for example HTTP 503, a timeout or a missing keyword), when it started, and buttons to acknowledge or view the incident. - Still down: a reminder with the time so far, if you set a repeat interval on the monitor's channel (every 5 to 1440 minutes). Acknowledging the incident stops reminders. - Up: the recovery with the cause and the total downtime, in the same channel. - SSL certificate expiry: a warning on the days you chose before a certificate expires. - Grouped alert: if alert grouping is on and several monitors fail within a few minutes, one message lists them all instead of one message each. Messages use Slack's colour bar (red for down, green for up, amber for SSL warnings), so the channel reads at a glance. Monitor names are escaped, so a name cannot mention @channel or hide a link. ### Acknowledging from Slack The Acknowledge button opens the incident in Upcertain, where a signed-in owner, admin or editor confirms it. Acknowledging stops reminders on every channel and records who took it. The recovery message follows in the same channel when the monitor is up again; Upcertain does not use threads. ### Keeping the channel useful - Route by owner: payments monitors to #payments-oncall, marketing sites to #web. Each monitor picks its own channels. - Use confirmation checks so a single dropped request never posts. - Delay a channel by a few minutes for services where a short blip is not worth a message, and keep email or a second channel immediate. - Turn on alert grouping (Settings, owners and admins) so an outage of a shared dependency posts one message, not twenty. #### Do I need to install a Slack app from Upcertain? No. Upcertain posts through the incoming webhook you create, so it never gets access to read your workspace. #### Can I post to a private channel? Yes, if you can create an incoming webhook for that channel in Slack. Upcertain only needs the webhook URL. #### Is the webhook URL stored safely? It is encrypted at rest and shown in the app only in shortened form, enough to recognise but not to use. ## Google Chat uptime alerts Source: https://upcertain.com/channels/google-chat If your team works in Google Workspace, alerts belong in the Google Chat space where the people who fix things already talk. ### Create the webhook in Google Chat 1. Open the space that should receive alerts. 2. Open the space menu, then Apps & integrations, then Webhooks. 3. Choose Add webhook, give it a name such as Upcertain and, if you like, an avatar URL. 4. Copy the URL. It starts with https://chat.googleapis.com/v1/spaces/ and carries a key and token. Incoming webhooks are available in Google Workspace accounts; your administrator may need to allow them. Personal Google accounts cannot create them. ### Add it in Upcertain 1. In Upcertain, open Settings, Alert channels and choose Google Chat. Owners, admins and editors can add channels. 2. Paste the webhook URL. 3. Pick the events to send: Down, Up (recovery) and SSL certificate expiry. 4. Tick Pre-select on new monitors if this should be the default for monitors you create from now on. Existing monitors keep their own choice. 5. Save, then use Send a test in the channel list to post a test message. 6. Open each monitor that should alert here and add the channel under its alert settings, with an optional delay and repeat interval. ### What arrives in the space - Down: the monitor's name and address, the cause (for example HTTP 503, a timeout or a missing keyword), when it started, and buttons to acknowledge or view the incident. - Still down: a reminder with the time so far, if you set a repeat interval on the monitor's channel (every 5 to 1440 minutes). Acknowledging the incident stops reminders. - Up: the recovery with the cause and the total downtime, in the same channel. - SSL certificate expiry: a warning on the days you chose before a certificate expires. - Grouped alert: if alert grouping is on and several monitors fail within a few minutes, one message lists them all instead of one message each. Each message is formatted text: the title in bold, the summary, the key fields and links that open the incident in Upcertain. Acknowledging happens in Upcertain itself, by a signed-in owner, admin or editor, and stops reminders on every channel. ### Spaces and routing A webhook posts into one space. Create one webhook per space and one Upcertain channel per webhook, then let each monitor choose its channels. A typical split is an operations space for outages and an infrastructure space for SSL warnings. ### If messages stop arriving - A deleted webhook or a removed space makes Google reject the message. The delivery is retried at 30 seconds, 1, 2 and 4 minutes before it is marked failed. - Use Send a test in Settings, Alert channels to check the URL after any change in Google Chat. - Keep an email channel on important monitors as well, so an outage is never only in one place. #### Can Upcertain post into a thread? No. Each alert and its recovery are separate messages in the space. #### Does it need a Google Cloud project or a Chat app? No. A space webhook is enough; Upcertain sends JSON to that URL. ## Microsoft Teams uptime alerts Source: https://upcertain.com/channels/microsoft-teams Upcertain posts to a Teams channel through a Workflows webhook, so alerts arrive in the channel your team already watches, as a card with buttons. ### Create the workflow in Teams 1. In the Teams channel, open the ... menu and choose Workflows (or add the Workflows app to the channel). 2. Pick the template Post to a channel when a webhook request is received. 3. Confirm the team and channel, then create the workflow. 4. Copy the URL Teams shows. It ends in .webhook.office.com, .logic.azure.com or .powerplatform.com. ### Add it in Upcertain 1. In Upcertain, open Settings, Alert channels and choose Microsoft Teams. Owners, admins and editors can add channels. 2. Paste the webhook URL. 3. Pick the events to send: Down, Up (recovery) and SSL certificate expiry. 4. Tick Pre-select on new monitors if this should be the default for monitors you create from now on. Existing monitors keep their own choice. 5. Save, then use Send a test in the channel list to post a test message. 6. Open each monitor that should alert here and add the channel under its alert settings, with an optional delay and repeat interval. ### What arrives in the channel - Down: the monitor's name and address, the cause (for example HTTP 503, a timeout or a missing keyword), when it started, and buttons to acknowledge or view the incident. - Still down: a reminder with the time so far, if you set a repeat interval on the monitor's channel (every 5 to 1440 minutes). Acknowledging the incident stops reminders. - Up: the recovery with the cause and the total downtime, in the same channel. - SSL certificate expiry: a warning on the days you chose before a certificate expires. - Grouped alert: if alert grouping is on and several monitors fail within a few minutes, one message lists them all instead of one message each. Each alert is an Adaptive Card with the title, summary and fields, and buttons to acknowledge or open the incident. The acknowledge button opens Upcertain, where a signed-in owner, admin or editor confirms it. ### Things that trip people up - The workflow belongs to its creator. If that person leaves the organisation, the workflow can stop. Create it with a shared or service account if your tenant allows. - Tenant policy. Some organisations block Workflows or external webhooks; your Microsoft 365 administrator can allow the template. - Retries. A rejected message is retried at 30 seconds, 1, 2 and 4 minutes, then marked failed. ### Routing alerts Each monitor chooses its channels, so customer-facing services can alert the support channel while internal tools alert only the platform team. Add confirmation checks so a single failed request never posts, and delay a channel for minor services if you prefer. #### Does Upcertain need a Teams app or Azure registration? No. It only needs the workflow's webhook URL. #### Can I alert several Teams channels? Yes. Create a workflow per channel and add each as its own Upcertain channel. ## Discord downtime alerts Source: https://upcertain.com/channels/discord Plenty of small teams, open-source projects and game servers run on Discord. A channel webhook brings downtime alerts there. ### Create the webhook in Discord 1. Open the channel's settings (the gear next to its name). 2. Choose Integrations, then Webhooks, then New Webhook. 3. Name it, for example Upcertain, and check it posts to the right channel. 4. Choose Copy Webhook URL. It starts with https://discord.com/api/webhooks/. You need the Manage Webhooks permission on the server. Anyone with the URL can post to the channel, so treat it like a password. ### Add it in Upcertain 1. In Upcertain, open Settings, Alert channels and choose Discord. Owners, admins and editors can add channels. 2. Paste the webhook URL. 3. Pick the events to send: Down, Up (recovery) and SSL certificate expiry. 4. Tick Pre-select on new monitors if this should be the default for monitors you create from now on. Existing monitors keep their own choice. 5. Save, then use Send a test in the channel list to post a test message. 6. Open each monitor that should alert here and add the channel under its alert settings, with an optional delay and repeat interval. ### What arrives in the channel - Down: the monitor's name and address, the cause (for example HTTP 503, a timeout or a missing keyword), when it started, and buttons to acknowledge or view the incident. - Still down: a reminder with the time so far, if you set a repeat interval on the monitor's channel (every 5 to 1440 minutes). Acknowledging the incident stops reminders. - Up: the recovery with the cause and the total downtime, in the same channel. - SSL certificate expiry: a warning on the days you chose before a certificate expires. - Grouped alert: if alert grouping is on and several monitors fail within a few minutes, one message lists them all instead of one message each. Alerts are embeds with a coloured edge (red, green or amber), the summary and the key fields, plus links to acknowledge or view the incident in Upcertain. ### Public status for your community If your users ask "is it down?" in Discord, pair the alert channel with a status page and pin its address. Your team gets the detail in a private channel; everyone else reads the status page. ### Good practice - Keep alerts in a private staff channel; post updates for users yourself. - Use a repeat interval only on critical monitors, so the channel does not fill with reminders. - Use Send a test after changing the channel's webhook in Discord. #### Will alerts ping @everyone? No. Upcertain does not add mentions to Discord messages. #### Can I monitor a game server? Yes, with a port monitor on the server's TCP port or a ping monitor on its host. ## Signed webhooks for down, recovery and SSL events Source: https://upcertain.com/channels/webhooks Webhooks send every alert as JSON to a URL you control, so you can open tickets, page through your own tooling or record outages anywhere. ### Set it up 1. In Upcertain, open Settings, Alert channels and choose Webhook. Owners, admins and editors can add channels. 2. Paste the webhook URL. Use an https:// address that is reachable from the internet; private and local addresses are refused. Add a signing secret so you can verify each request. 3. Pick the events to send: Down, Up (recovery) and SSL certificate expiry. 4. Tick Pre-select on new monitors if this should be the default for monitors you create from now on. Existing monitors keep their own choice. 5. Save, then use Send a test in the channel list to post a test message. 6. Open each monitor that should alert here and add the channel under its alert settings, with an optional delay and repeat interval. ### Events Event | Sent when monitor.down | An incident opens after a confirmed failure monitor.still_down | A reminder, if the monitor's channel has a repeat interval monitor.up | The monitor recovers and the incident resolves ssl.expiring | A certificate reaches one of its warning days monitors.down_grouped | Alert grouping combined several failures into one alert test.channel, test.down, test.up | You sent a test from the app ### Request Each delivery is a POST with a JSON body and these headers: - X-Upcertain-Event: the event name. - X-Upcertain-Timestamp: Unix seconds when the request was signed. - X-Upcertain-Delivery: a unique id; the same id is reused when a delivery is retried, so you can ignore duplicates. - X-Upcertain-Signature: v1= followed by the hex HMAC-SHA256 of timestamp + "." + body, keyed with your signing secret. Sent only when the channel has a secret. { "delivery_id": "6f1c...", "sent_at": "2026-10-25T09:14:03.000Z", "event": "monitor.down", "title": "Down: payments-api", "summary": "payments-api is down: HTTP 503.", "account": "Acme", "fields": [ { "label": "Monitor", "value": "https://api.example.com/health" }, { "label": "Root cause", "value": "HTTP 503" }, { "label": "Started", "value": "25 Oct 2026, 09:13:21 UTC" } ], "links": { "acknowledge": "https://upcertain.com/incidents/?ack=1", "view_incident": "https://upcertain.com/incidents/" }, "monitor": { "id": "...", "name": "payments-api", "type": "http", "target": "https://api.example.com/health" }, "incident": { "id": "...", "started_at": "2026-10-25T09:13:21.000Z", "resolved_at": null, "cause": "status_code", "cause_detail": "HTTP 503", "status_code": 503 } } ssl.expiring adds days_left, threshold_days and expires_at. monitors.down_grouped adds a monitors list. Treat unknown fields as optional: new ones may be added. ### Verify the signature import { createHmac, timingSafeEqual } from "node:crypto"; // rawBody: the request body exactly as received, before JSON parsing. export function verify(rawBody: string, headers: Headers, secret: string): boolean { const ts = headers.get("x-upcertain-timestamp") ?? ""; const sig = headers.get("x-upcertain-signature") ?? ""; if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false; // reject replays const expected = "v1=" + createHmac("sha256", secret).update(`${ts}.${rawBody}`).digest("hex"); return sig.length === expected.length && timingSafeEqual(Buffer.from(sig), Buffer.from(expected)); } import hashlib, hmac, time def verify(raw_body: bytes, headers, secret: str) -> bool: ts = headers.get("X-Upcertain-Timestamp", "") sig = headers.get("X-Upcertain-Signature", "") if abs(time.time() - int(ts or 0)) > 300: return False mac = hmac.new(secret.encode(), f"{ts}.".encode() + raw_body, hashlib.sha256).hexdigest() return hmac.compare_digest(sig, "v1=" + mac) ### Delivery and retries Answer with any 2xx status within a few seconds. Anything else, or no answer, is retried at 30 seconds, 1 minute, 2 minutes and 4 minutes; after the fifth attempt the delivery is marked failed. Deliveries are at least once, so use X-Upcertain-Delivery to drop duplicates. #### Can I receive webhooks on a private network address? No. To protect both sides, Upcertain refuses webhook URLs that resolve to private, loopback or link-local addresses. #### Is there an API to read monitors and incidents as well? Yes. The REST API and the MCP server are described in the MCP and API docs. ## Email downtime alerts Source: https://upcertain.com/channels/email Email is the channel everyone has. Upcertain sends each recipient their own copy, so anyone can stop their alerts without changing anyone else's. ### Set it up 1. In Settings, Alert channels, choose E-mail. Owners, admins and editors can add channels. 2. Enter up to 20 addresses, separated by commas. 3. Pick the events: Down, Up (recovery) and SSL certificate expiry. 4. Save, use Send a test, then add the channel to the monitors it should cover. When you sign up, your account starts with an email channel for your own address, attached to new monitors, so the first monitor alerts someone straight away. ### One copy per recipient Each address receives its own email rather than one message with everyone in copy. That keeps addresses private from each other and lets each recipient have a personal stop link at the bottom. Mail clients that support one-click unsubscribe (RFC 8058) also show their own unsubscribe button, which works straight away. ### Acknowledge from the email Down alerts carry an Acknowledge button, but only for recipients who can acknowledge: owners, admins and editors of the account. Others, such as a client who just wants to know, get the same alert without the button. ### What arrives - Down: the monitor, its address, the cause, when it started, and links to acknowledge or view the incident. - Still down: reminders at the interval you set for the monitor's channel, until someone acknowledges. - Up: the recovery with the total downtime. - SSL certificate expiry: a warning on each day you chose before expiry. ### People without a login Add people who only need to hear about outages, such as a manager or a client, as notify-only contacts under Team. They receive email alerts for the events you choose and have no login. ### Weekly and monthly reports Under Settings, Notifications, owners and admins can turn on a weekly report (sent on Mondays) or a monthly one (on the 1st) with the previous period's uptime and incidents. It goes to members who receive email notifications. ### Delivery Alerts are sent from alerts@upcertain.com. Add it to your contacts or allow-list so alerts never land in spam. A failed send is retried at 30 seconds, 1, 2 and 4 minutes. #### Can I send alerts to a distribution list? Yes. Add the list's address like any other; it counts as one of the 20 addresses. #### Can I get SMS or phone calls? No. Upcertain alerts by email, chat tools and webhooks. A webhook can feed a paging service that calls or texts. ## Put a status page on your own domain Source: https://upcertain.com/docs/status-pages/custom-domain A status page on your own subdomain looks like part of your product and keeps working links in your docs and emails. Setup is one DNS record. ### Before you start - Custom domains are included on the Team and Business plans. - Owners and admins connect domains. - Use a subdomain you are not using for anything else, such as status.yourcompany.com. - You need access to the DNS settings where your domain is managed (Cloudflare, Route 53, GoDaddy and so on). ### 1. Connect the domain in Upcertain 1. Open Status pages, choose the page and open its settings. 2. In Custom domain, enter the hostname, for example status.yourcompany.com, and press Connect. 3. Upcertain shows the DNS record to add, with a copy button. ### 2. Add the CNAME record Where your DNS is managed, create a CNAME record from your hostname to pages.upcertain.com: Type | Name | Value CNAME | status | pages.upcertain.com On Cloudflare, set the record to DNS only (grey cloud). Proxying it through Cloudflare hides the CNAME, and Upcertain cannot issue the certificate. ### 3. Verify Press Verify once the record is saved. Pending domains are also re-checked every 5 minutes for 72 hours, so you can close the page and come back. When the record is found the domain shows Verified. Live at https://status.yourcompany.com. The first visit to the new address triggers the HTTPS certificate from Let's Encrypt. Open it once yourself; it may take a few seconds the first time. ### When a TXT record is also needed If another Upcertain account has claimed or verified the same hostname before, a CNAME alone does not prove the domain is yours. Upcertain then shows a TXT record as well: Type | Name | Value TXT | _upcertain.status | upcertain-verify= ### If verification fails - Check the record from outside your network: dig +short CNAME status.yourcompany.com should print pages.upcertain.com. - DNS changes can take a while to reach every resolver; your provider's TTL decides how long. - A claim expires 72 hours after you connect the domain. To start a new window, remove the domain and connect it again. - A hostname can serve only one status page at a time. ### What the domain serves Your domain serves the status page and its incident history. The Upcertain app, the REST API and the MCP server stay on upcertain.com. The page is also still reachable at its upcertain.com/s/ address. #### Can I use my root domain (yourcompany.com)? Use a subdomain. Root domains cannot carry a CNAME record at most DNS providers, and your main site usually lives there. #### Do I need to renew the certificate? No. Upcertain requests and renews the Let's Encrypt certificate for your hostname on its own, as long as the CNAME stays in place. ## Password-protected and private status pages Source: https://upcertain.com/docs/status-pages/password-protection Not every status page should be public. An internal tools page or a page for one large customer can sit behind a password, or be visible only to your own team. ### Three kinds of visibility Visibility | Who can see it | Search engines Public | Anyone with the address | Indexed Password | Anyone who enters the password | Not indexed Private | Signed-in members of your account | Not indexed ### Set a password 1. Open Status pages, choose the page and open its settings. 2. Under General, choose Password as the visibility. 3. Enter a password of at least 6 characters and save. 4. Share the page address and the password with the people who need them. Visitors see a password form instead of the page. After entering the right password once, their browser keeps access for 30 days. Changing the password signs out everyone who entered the old one, which is also how you revoke access. ### Make a page private Choose Private to show the page only to people signed in to your Upcertain account. Use it for an internal overview your support team checks during incidents, without handing out another password. ### How it is protected - The password is stored as a hash, never in plain text. - Wrong guesses are limited to 5 a minute per address. - Protected and private pages tell search engines not to index them. - The access cookie is HttpOnly and sent only over HTTPS. ### With a custom domain Password protection works the same on a custom domain. A password page on status.yourcompany.com asks for the password there. #### Can different customers have different passwords? Each page has one password. Create one page per customer, each with its own monitors and password; Team and Business include unlimited pages. #### Can I see who opened the page? No. Upcertain does not track status page visitors. ## Set up a heartbeat monitor for a cron job Source: https://upcertain.com/docs/monitors/heartbeat A heartbeat monitor waits for your job to report in. Here is how to create one and add the call to the most common kinds of scheduled job. ### Create the monitor 1. Choose New monitor, then Heartbeat (cron job) monitoring. 2. Set how often the job runs: from every 30 seconds to every 30 days. 3. Set a grace period for jobs whose run time varies, up to one day. The default is 60 seconds. 4. Pick the alert channels and save. Copy the heartbeat URL shown on the monitor. The URL looks like https://upcertain.com/api/heartbeat/. It accepts GET, POST and HEAD, and answers with JSON containing "ok": true when the call is recorded. The examples below use ; paste your own URL. ### cron */15 * * * * /opt/jobs/sync.sh && curl -fsS -m 10 --retry 3 -o /dev/null https://upcertain.com/api/heartbeat/ && sends the heartbeat only when the job succeeds. -m 10 gives up after 10 seconds and --retry 3 rides out a brief network failure. ### Node.js async function nightlyReport() { await buildReport(); // Report in only after the work is done. await fetch("https://upcertain.com/api/heartbeat/", { signal: AbortSignal.timeout(10_000) }); } ### Python import urllib.request def main(): run_backup() urllib.request.urlopen("https://upcertain.com/api/heartbeat/", timeout=10) ### PHP and Laravel // Laravel scheduler: ping after a successful run $schedule->command('reports:send') ->daily() ->thenPing('https://upcertain.com/api/heartbeat/'); '); thenPing pings after the task runs, whatever the outcome. Use pingOnSuccess instead to ping only when the task succeeds. ### GitHub Actions on: schedule: - cron: "0 * * * *" jobs: sync: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: ./scripts/sync.sh - name: Report to Upcertain if: success() run: curl -fsS -m 10 --retry 3 "${{ secrets.UPCERTAIN_HEARTBEAT_URL }}" GitHub may start scheduled workflows late at busy times. Give the monitor a grace period of 15 to 30 minutes for hourly workflows. ### Pick the period and grace - Period: how often the job is meant to run. A job every 15 minutes gets a 15-minute period. - Grace: the longest normal delay plus the longest normal run time. A backup that starts at 02:00 and takes up to 40 minutes needs about 45 minutes of grace. - Too little grace means alerts on slow nights; too much means you hear late. Start generous and tighten it after a week. ### Limits Calls from one address may burst to 30 and then one a second; beyond that the endpoint answers 429. Calls for the same monitor within 5 seconds share one answer. Keep the URL private: anyone who has it can report in for the job. If it leaks, create a new heartbeat monitor and delete the old one. ## Connect Upcertain to Claude Source: https://upcertain.com/docs/mcp/claude With Upcertain connected, Claude can answer "what is down right now?" or "how did the API do over the last 30 days?" from your real monitors, and act on them if you allow it. ### Before you start - Your Upcertain account needs the Team or Business plan, which include MCP. - Any member except notify-only members can connect their own apps. - Adding custom connectors in Claude depends on your Claude plan and, in organisations, on your administrator. ### Add the connector 1. In Claude (claude.ai or the desktop app), open Settings, then Connectors. 2. Choose Add custom connector. 3. Name it Upcertain and paste the server address: https://upcertain.com/api/mcp. 4. Choose Connect. Claude opens Upcertain in your browser. ### Approve the connection 1. Sign in to Upcertain if you are not already. 2. Pick the workspace Claude may use, if you belong to more than one. 3. Choose Read-only (the default) or Read-write. Read-write lets Claude create, pause and resume monitors and acknowledge incidents, and is offered only if your role can make those changes. 4. Approve. You return to Claude with Upcertain connected. ### Things to ask - "Which monitors are down right now, and since when?" - "List this week's incidents on the payments API with their causes and durations." - "Make a table of 30-day uptime for every monitor, worst first." - "Add a keyword monitor for https://example.com that checks for Welcome every 5 minutes." (read-write) - "Acknowledge the open incident on checkout." (read-write) ### Manage and disconnect Every connection is listed in Upcertain under Settings, API & MCP, Connected apps. You can disconnect your own; owners and admins can disconnect anyone's. A connection follows your membership: if you leave the account or become notify-only it ends, and if your role can no longer make changes it becomes read-only. ### Using an API key instead Claude Desktop can also reach Upcertain through a local bridge with an API key, which owners and admins create. The configuration is on the MCP server page. Sign-in is simpler and gives each person their own revocable connection. #### Can Claude see other accounts' monitors? No. A connection is tied to one Upcertain workspace and to your access in it. #### What can Claude do with a read-only connection? Read monitors, uptime, incidents and status pages. It cannot change anything. ## Use Upcertain from Claude Code Source: https://upcertain.com/docs/mcp/claude-code Claude Code can check whether the service you are changing is healthy, look up the incident from last night, or add monitors for an endpoint you just shipped. ### Add the server claude mcp add --transport http upcertain https://upcertain.com/api/mcp Then start Claude Code, run /mcp, select upcertain and choose Authenticate. Your browser opens Upcertain, where you pick the workspace and read-only or read-write access. Your account needs the Team or Business plan. ### With an API key For scripts, CI or a machine without a browser, an owner or admin creates an API key under Settings, API & MCP and you pass it as a header: claude mcp add --transport http upcertain https://upcertain.com/api/mcp --header "Authorization: Bearer " Keep the key out of version control. A read-only key cannot change monitors or incidents. ### Useful while coding - "Before I deploy, are any monitors for the API down or flapping today?" - "What caused last night's incident on auth-service, and how long did it last?" - "I just added /v2/health. Create an HTTP monitor for it every minute, expecting 200." (read-write) - "Pause the monitor for the staging site while I migrate it." (read-write) ### Tools available Read tools: list_monitors, get_monitor, get_uptime, list_incidents, get_incident, list_status_pages. Read-write tools: create_monitor, pause_monitor, resume_monitor, acknowledge_incident. Arguments and limits are on the MCP server page. ### Scope Add the server with --scope user to use it in every project, or leave the default to keep it in the current project only. Remove it with claude mcp remove upcertain, and disconnect the sign-in under Settings, API & MCP, Connected apps. ## Use Upcertain in Cursor Source: https://upcertain.com/docs/mcp/cursor Cursor's agent can read your monitors and incidents through Upcertain's MCP server, so production health is one question away while you edit. ### Sign in (recommended) Add this to ~/.cursor/mcp.json for every project, or .cursor/mcp.json in one project: { "mcpServers": { "upcertain": { "url": "https://upcertain.com/api/mcp" } } } Open Cursor's MCP settings and choose Connect next to upcertain. Your browser opens Upcertain, where you pick the workspace and read-only or read-write access. Your account needs the Team or Business plan. ### With an API key { "mcpServers": { "upcertain": { "url": "https://upcertain.com/api/mcp", "headers": { "Authorization": "Bearer " } } } } Owners and admins create keys under Settings, API & MCP. Do not commit a project mcp.json that contains a key. ### Also works in VS Code code --add-mcp '{"name":"upcertain","type":"http","url":"https://upcertain.com/api/mcp"}' ### Things to ask in the editor - "Is the endpoint this file serves monitored? If not, add a monitor for it." (read-write) - "Show the last three incidents on the checkout API and their causes." - "Which monitors have the lowest 7-day uptime?" ### Troubleshooting - 401 or a sign-in loop: remove the server, add it again and reconnect. Check that the connection was not removed under Connected apps. - Write tools refused: a read-only connection or key lists every tool but refuses the ones that make changes. Reconnect with read-write if your role allows it. - Too many requests: tool calls share the API's limit of 60 a minute per key or connected app. ## Email subscribers on a status page Source: https://upcertain.com/docs/status-pages/subscribers Subscribers hear from you without checking the page. They get an email for each announcement you publish: an incident update, planned maintenance or general news. ### Turn subscriptions on Subscriptions are on by default for public pages. To change it, open the status page, then Appearance, and use Enable subscribe. With it on, the page shows a subscribe form. ### How a visitor subscribes 1. The visitor enters an email address on the status page. 2. Upcertain sends a confirmation email. Nothing more is sent until it is confirmed. 3. The visitor presses the button in that email. Opening the link alone does not confirm it, so mail scanners that open links cannot subscribe anyone by accident. ### Send an announcement 1. Open the status page and find Announcements. 2. Write a title and a body, and choose the type: Information, Incident update or Maintenance. 3. Save it as a draft, or publish it. Publishing shows it on the page and emails every confirmed subscriber. Subscribers receive the announcements you publish. Incidents opened by monitors appear on the page automatically but are not emailed on their own, so you decide what is worth a message. ### Unsubscribing Every announcement carries an unsubscribe link. It opens a page with a button, again so a mail scanner cannot unsubscribe anyone. Mail clients that support one-click unsubscribe (RFC 8058) show their own unsubscribe button, which works straight away. ### See who is subscribed The Subscribers list on the page shows how many addresses are confirmed and how many are waiting for confirmation. ### Good practice - Publish an incident update when customers notice the problem, not for every blip. - Announce maintenance a few days ahead, then again when it starts if it affects customers. - Close the loop: a short note when an incident is resolved is the message people read most. ## Schedule maintenance windows Source: https://upcertain.com/docs/status-pages/maintenance Planned work should not wake anyone up or lower your uptime. A maintenance window tells Upcertain when to expect failures, and tells your customers in advance. ### Create a window 1. Open Maintenance in the app and create a window. 2. Give it a name, the date and time it starts, a duration in minutes (up to 7 days) and the time zone. 3. Choose how often it repeats: once, every day, on chosen weekdays, or on a day of the month. 4. Pick the monitors it covers, and save. Times are wall-clock times in the window's time zone, so a window at 02:00 stays at 02:00 when the clocks change. A monthly window on the 31st is skipped in months that have no 31st. ### What happens during the window - Checks keep running, so you can watch the work from the monitor pages. - Failures do not open incidents and nobody is alerted. - The time counts as maintenance, not downtime, in uptime figures. - Status pages show the monitors as under maintenance. An incident that was already open when the window starts stays open, and its reminders wait until the window ends. Resolve or acknowledge it first if the work explains it. ### On status pages Upcoming maintenance for monitors on a page appears in its own section ahead of time, so customers see it before it starts. To also email subscribers, publish an announcement of the type Maintenance; see subscribers. ### Changing or deleting a window Editing a window changes its future occurrences. Deleting it removes future occurrences, while past ones still count as maintenance, so your uptime history does not change after the fact. Overlapping windows count once. ## Add a status badge to your README or website Source: https://upcertain.com/docs/status-pages/badge A badge shows at a glance whether everything is up, and links to the full status page. It updates on its own. ### Get the code 1. Open the status page's settings and find Status badge. Badges are available for public pages. 2. Choose the text badge or the logo badge. 3. Copy the Markdown, the HTML or the website embed. [![Acme status](https://upcertain.com/badge/acme.svg)](https://upcertain.com/s/acme) Acme status ### Styles and states Badge | What it says Text (?style=text, the default) | All services are up, Partial outage, Major outage or Maintenance Logo (?style=logo) | The Upcertain mark with up, partial outage, down or maintenance Add &theme=dark for a dark background, for example https://upcertain.com/badge/acme.svg?style=logo&theme=dark. The state is spelled out in words, not only shown by colour. ### Freshness The badge is an SVG image cached for one minute, so it follows the page's state closely without slowing your site. GitHub caches images through its own proxy, which can add a few minutes in READMEs. ### Where to put it - The README of your API client or SDK, next to the version badge. - Your documentation's header or footer. - Your app's help or support page. #### Does the badge work for password-protected pages? No. Badges are offered for public pages only, so a badge never reveals the state of a protected page. #### Can I change the badge's wording? No. The wording follows the page's state so it always matches the status page. ## HTTP monitors: options and status codes Source: https://upcertain.com/docs/monitors/http An HTTP monitor requests a URL and decides whether the answer counts as up. These are the options that decide it. ### Request Option | Values | Default URL | http:// or https://, up to 2,048 characters | required Method | GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS | GET Headers | Up to 30, values up to 4,096 characters | none Body | Up to 64 KB, sent with methods other than GET and HEAD | none Basic authentication | Username and password | none Timeout | 1 to 60 seconds | 30 seconds Follow redirects | On or off | on ### Expected status codes By default any status from 200 to 399 is up. Write your own rule as a comma-separated list of codes, classes and ranges: - 200 exactly 200. - 2xx any 2xx status. - 200-299, 301 a range plus one code. - 401 useful for endpoints that must refuse anonymous requests, such as an API behind authentication. ### Certificates HTTPS monitors check the certificate on every request: an expired certificate, a hostname mismatch or a broken chain fails the check. Warnings are sent before expiry, by default 30, 14 and 7 days ahead; you can choose up to five days between 1 and 90. See SSL monitors. ### Interval and confirmation Choose the interval (30 s to 24 h, limited by your plan) and, under Advanced settings, how many confirmation checks run before an incident opens and how far apart. See confirmation checks. ### What a failure records The incident names the cause: the status code, a timeout, a DNS failure, a refused connection, too many redirects or the certificate problem. The response time recorded with each check is the time to the response headers. ### Requests from Upcertain Checks come from Seoul with the user agent Upcertain-Monitor/1.0 (+https://upcertain.com). Upcertain refuses to check private, loopback and link-local addresses, including where a redirect leads. ## Keyword monitors: check what a page says Source: https://upcertain.com/docs/monitors/keyword A keyword monitor is an HTTP monitor that also reads the page. It catches the failures that still return 200. ### Two modes Mode | Up when | Use it for Must contain | The word or phrase is on the page | A product name, a price label, a known heading, "status":"ok" in a health response Must not contain | The word or phrase is absent | "Something went wrong", "Maintenance", "Database error" ### Set it up 1. Choose New monitor, then Keyword monitoring. 2. Enter the URL and the keyword, up to 500 characters. 3. Choose whether it must be present or absent, and whether the match is case-sensitive (off by default). 4. Set the expected status codes as for any HTTP monitor; both the status and the keyword must pass. ### What is searched The response body as the server sent it, up to the first 1 MB. That means the HTML source, not the page after JavaScript runs. For a single-page app, check a server-rendered page or a health endpoint whose JSON includes the word. ### Choosing a good keyword - Pick text that only appears when the page works: a product grid's "Add to basket" rather than your company name, which also appears on the error page. - Avoid text that changes, such as dates, prices that move, or A/B-tested headings. - For JSON health checks, include the quotes: "status":"ok". A failure records Keyword missing or Keyword present as the cause, so the alert says why the page was judged down. ## Ping monitors: check that a host is reachable Source: https://upcertain.com/docs/monitors/ping A ping monitor answers one question: is the host reachable from the internet? It suits servers, routers and devices without a web page to check. ### How it checks 1. In ICMP mode (the default) it sends one ICMP echo request. A reply means up. 2. Without a reply, or in TCP mode, it tries a TCP connection on port 443, then port 80. 3. A connection, or even a refused connection, means up: a refusal proves the host answered. 4. No ICMP reply and no TCP answer within the timeout means down. Many networks drop ICMP. The TCP fallback keeps a firewall that blocks ping from looking like an outage. The check log notes when a result came from the fallback, for example TCP reachability (port 443, no ICMP reply). ### Set it up 1. Choose New monitor, then Ping monitoring. 2. Enter a hostname or IP address. Private and local addresses are refused. 3. Pick ICMP or TCP mode, the timeout and the interval. ### When to use something else - To know a specific service answers (a database, SMTP, SSH), use a port monitor. - To know a website or API works, use an HTTP monitor. A host can answer ping while its web server is down. #### Which address family is used? The hostname is resolved and checked at the address it resolves to, IPv4 or IPv6. #### What does the response time mean for ping? The round-trip time of the ICMP reply, or the time to open the TCP connection when the fallback answered. ## Port monitors: check a TCP service Source: https://upcertain.com/docs/monitors/port A port monitor opens a TCP connection to a host and port. If the connection opens in time, the service is up. ### Set it up 1. Choose New monitor, then Port monitoring. 2. Enter the host and the port, from 1 to 65535. 3. Set the timeout (1 to 60 seconds) and the interval. ### Common ports Service | Port SMTP (submission) | 587, or 25 for server-to-server IMAP over TLS | 993 PostgreSQL | 5432 MySQL | 3306 Redis | 6379 SSH | 22 Game or custom servers | whatever the server listens on ### What it does and does not prove A successful connection proves the host is reachable and something is listening on the port. It does not log in or run a query, so a database that accepts connections but refuses every query still looks up. For a deeper check, expose a small health endpoint that runs a query and monitor it over HTTP. ### Failures - Connection refused: the host answered but nothing listens on the port. - TCP timeout: no answer at all, often a firewall dropping the connection or the host being down. - DNS failure: the hostname did not resolve. ### Security Only monitor ports that are meant to be reachable from the internet. If your database should not be public, monitor it from inside your network with a heartbeat instead: a small job that checks the database and calls its heartbeat URL. ## SSL certificate monitors and expiry warnings Source: https://upcertain.com/docs/monitors/ssl An SSL monitor watches a certificate on its own, without checking the page behind it. Use it when certificate warnings should go somewhere different from outages. ### Set it up 1. Choose New monitor, then SSL certificate monitoring. 2. Enter the hostname whose certificate to check, such as api.example.com, and the port if it is not 443. 3. Choose the warning days: up to five, from 1 to 90 days before expiry. The default is 30, 14 and 7. 4. Pick the alert channels. A channel receives warnings only if it has the SSL certificate expiry event ticked. ### What fails the check - The certificate has expired. - It does not cover the hostname. - The chain does not lead to a trusted root, often a missing intermediate certificate. ### What a warning says "SSL certificate expires in 14 days" with the host, the exact expiry time in your account's time zone, and the issuer. Each chosen day sends one warning per certificate. Webhooks receive the event ssl.expiring with days_left, threshold_days and expires_at. ### HTTP monitors already do this Every HTTPS HTTP monitor checks its certificate and sends the same warnings. Add a separate SSL monitor when the host is not otherwise monitored, or when certificates are someone else's job and their warnings should go to that person's channel. #### Does an SSL monitor check the page's status code? No. It only checks the certificate. Use an HTTP monitor to check that the page works as well. #### Can I monitor a certificate that is not on port 443? Yes. Enter the hostname and put the port in the Port field, which defaults to 443. ## Import monitors from a CSV file Source: https://upcertain.com/docs/monitors/import-csv Moving from another tool, or setting up a client with fifty sites? Import them in one go instead of filling the form fifty times. ### Start an import Next to New monitor, open the menu and choose Import from CSV. Upload a file or paste the text. ### The simplest file One URL or host per line, no header. Each line becomes an HTTP monitor with the default interval: https://example.com https://example.com/login https://api.example.com/health ### With columns With a header row, Upcertain reads these columns; leave out the ones you do not need: Column | Meaning type | http, keyword, ping, port or ssl (heartbeats are added one at a time) name | Display name url | For HTTP and keyword monitors host, port | For ping, port and SSL monitors interval | 30s, 1 min, 5 minutes, 12h, 1d or plain seconds such as 300 keyword | For keyword monitors group | Group name; created if it does not exist tags | Tags for filtering type,name,url,host,port,interval,keyword,group http,Website,https://example.com,,,1 min,,Client A keyword,Shop,https://example.com/shop,,,5 min,Add to basket,Client A port,Mail,,mail.example.com,587,5 min,,Client A ### Preview and limits - Every row is shown before anything is created, with the monitor it will become or the reason it cannot. - Up to 200 rows per import. - Monitors beyond your plan's active limit are created paused, not refused. - Intervals faster than your plan allows are raised to the fastest allowed. Pick the alert channels for the imported monitors on the import page. Review confirmation checks afterwards, or set them for all at once with Confirmation on the monitor list. ## REST API reference Source: https://upcertain.com/docs/api Everything the MCP server offers is also a plain HTTP API, for scripts, CI pipelines and your own dashboards. It is available on every plan. ### Authentication Owners and admins create API keys under Settings, API & MCP, read-only or read-write. Send the key as a bearer token. Keys start with upc_ and are shown once; Upcertain stores only a hash. curl -H "Authorization: Bearer upc_..." https://upcertain.com/api/v1/monitors ### Endpoints Method and path | What it does GET /api/v1/account | Plan, limits, monitor counts and open incidents GET /api/v1/monitors | Monitors; filter with status (up, down, paused, pending) and type POST /api/v1/monitors | Create a monitor (read-write) GET /api/v1/monitors/{id} | One monitor PATCH /api/v1/monitors/{id} | Change a monitor (read-write) DELETE /api/v1/monitors/{id} | Delete a monitor (read-write) POST /api/v1/monitors/{id}/pause | Pause checks (read-write) POST /api/v1/monitors/{id}/resume | Resume checks (read-write) GET /api/v1/monitors/{id}/uptime | Uptime for window 24h, 7d, 30d or 90d GET /api/v1/incidents | Incidents; since (7d or an ISO date), status (ongoing, resolved), monitor_id, limit up to 200 GET /api/v1/incidents/{id} | One incident with its activity POST /api/v1/incidents/{id}/acknowledge | Acknowledge an incident (read-write) GET /api/v1/maintenance | Maintenance windows GET /api/v1/status-pages | Status pages with address and visibility ### Create a monitor curl -X POST https://upcertain.com/api/v1/monitors \ -H "Authorization: Bearer upc_..." \ -H "Content-Type: application/json" \ -d '{"type":"http","name":"API health","url":"https://api.example.com/health","intervalSec":60,"expectedStatus":"200"}' Fields follow the monitor form: type, name, url or host and port, intervalSec, keyword, expectedStatus, method, timeoutSec and so on. The interval defaults to 300 seconds and is limited by your plan. ### Responses and errors Successful responses wrap the result in { "data": ... }. Errors return { "error": { "code", "message" } } with a status code: Status | Code | Meaning 400 | validation_error, bad_request | The request was not valid; the message says which field 401 | unauthorized | Missing, malformed, revoked or unknown key 403 | read_only_key, account_suspended | The key cannot do this 404 | not_found | No such record in your account 429 | rate_limited | Too many requests; see Retry-After ### Rate limit 60 requests a minute per key, shared with MCP tool calls made with the same key. Each response carries X-RateLimit-Limit and X-RateLimit-Remaining. ## Working with incidents Source: https://upcertain.com/docs/incidents Every confirmed outage becomes an incident. This page covers what you can do with one, from the first alert to the export at the end of the month. ### When an incident opens and closes - It opens when a check fails and every confirmation check after it fails too. - Its start time is the first failed check, so the recorded duration matches what users saw. - It resolves on its own at the first passing check, and every channel that got the alert gets the recovery. - If the monitor fails again later, a new incident opens. Incidents are never reopened. ### Acknowledge Open the incident from the alert, or from Incidents in the app, and acknowledge it. Acknowledging records who took it and stops repeat reminders on every channel. Owners, admins and editors can acknowledge; email alerts show the button only to people who can use it. ### What the incident shows - The cause: a status code, a timeout, a missing or unwanted keyword, a DNS failure, a refused connection, a certificate problem or a missed heartbeat. - The failed request (method, URL and headers) and the response (status, headers and the start of the body), when the check made one. - A timeline of detection, confirmation, alerts, acknowledgement, notes and recovery. ### Notes for your team Add notes to the timeline: what you found, what you changed, who is on it. Notes are visible to members of the account, not on status pages. ### Tell customers Use Post status update on the incident to publish an update to the status pages that show the affected monitor. It appears on the page and goes by email to the page's subscribers. Short templates are in incident communication templates. ### Find and export The incident list searches by monitor, filters by status or tag and sorts. Export the list as CSV with the incident id, monitor, target, status, cause, status code, detail, start, resolution, duration in seconds and who acknowledged it. The REST API and the MCP server return the same records. ## Team roles and the audit log Source: https://upcertain.com/docs/team-roles Give each person the access they need and no more. Upcertain has five roles, from full control to email alerts without a login. ### Roles Role | Can Owner | Everything, including handing the account over and deleting it Admin | Everything else: team, plan, API keys, custom domains, alert grouping and reports, audit log Editor | Create and change monitors, status pages, alert channels and maintenance; acknowledge incidents Viewer | Read the dashboard Notify-only | Receive email alerts for chosen events; no login ### Invite people 1. Owners and admins open Team and invite by email, choosing the role. 2. The person gets an email and accepts with a button; they sign up or sign in. 3. Resending an invitation renews its link. Invitations expire if not accepted. Notify-only contacts are added from the same form, choosing the events they receive: down, up and SSL expiry. They never get a login. ### Seats and plans Basic has one seat: the owner. Team and Business include unlimited members. If a plan changes, existing members keep access and new invitations wait until there is room. ### Changing owners An owner hands an account over by making another member an owner. Account deletion is confirmed through a link sent by email. ### The audit log Owners and admins see Settings, Audit log: changes to members, API keys, plans, monitors, status pages and alert channels, with who made them and when. Entries are kept for 365 days. ### API keys and connected apps API keys are created by owners and admins and act with their creator's access. Any member except notify-only can connect their own apps over MCP, read-only unless their role can make changes. See the MCP server and the REST API. ## Confirmation checks: how to stop false downtime alerts Source: https://upcertain.com/learn/confirmation-checks Many false downtime alerts come from a single failed request: a dropped packet, a container restarting, a load balancer shuffling traffic. Confirmation checks make a monitor ask again before it raises the alarm. ### What a confirmation check is When a scheduled check fails, the monitor does not open an incident straight away. It checks again after a short delay, and again, up to the number of confirmation checks you set. The incident opens only if every one of them fails too. If any of them passes, nothing happens: no incident, no alert. In Upcertain each monitor has 0 to 5 confirmation checks, 15, 30, 60 or 120 seconds apart. New monitors start with one confirmation check after 15 seconds, which filters out single dropped requests while adding very little delay. Heartbeat monitors have none, because a missed deadline is already a confirmed failure. ### The trade-off: certainty against speed Every confirmation check adds its delay to the time before anyone hears about a real outage. Roughly, a failure that starts at a random moment is noticed by the next scheduled check, half an interval later on average, and then confirmed after the re-checks: Interval | Confirmation | Average time to alert | Slowest | Shorter failures ignored 30 s | none | 15 s | 30 s | none 30 s | 1 check after 15 s | 30 s | 45 s | under about 15 s 60 s | 1 check after 15 s | 45 s | 1 m 15 s | under about 15 s 30 s | 3 checks, 30 s apart | 1 m 45 s | 2 m | under about 90 s 60 s | 3 checks, 30 s apart | 2 m | 2 m 30 s | under about 90 s 5 min | 3 checks, 60 s apart | 5 m 30 s | 8 m | under about 3 min The times ignore how long each request takes; a check that runs into its timeout adds that timeout too. The last column is the point of the exercise: a failure has to outlast the confirmation window to become an incident. ### How to choose 1. Start with the shortest failure you want to hear about. If a 30-second blip on your marketing site does not matter but a 2-minute outage does, the confirmation window should sit between the two. 2. Measure your known noise. Deploys, nightly restarts and failovers produce failures of a predictable length. Set the window just longer than they last. The guide to false alarms during deploys works through an example. 3. Keep the interval short and confirm instead. A 30-second interval with a 90-second confirmation window still notices a real outage within about two minutes. A 5-minute interval without confirmation is slower and still fires on blips. 4. Different services, different settings. A payment API may deserve one quick re-check; a batch-processing dashboard can wait for three. ### What confirmation does not replace - Maintenance windows for planned work. Time inside a window counts as maintenance, so a planned migration never opens an incident at all. - Alert delays per channel. Upcertain can delay one channel, say email to managers, by several minutes while Slack is told at once. - Fixing the cause. If a service fails for 60 seconds on every deploy, its users feel those 60 seconds. Confirmation keeps the pager quiet; zero-downtime deploys keep the users happy. ### Setting it in Upcertain Open a monitor, then Advanced settings, and set the number of confirmation checks and the time between them. To change many monitors at once, select them in the monitor list and use Confirmation. Heartbeat monitors are skipped. ### Why not just check from several places? Tools that check from many regions confirm by asking a second location at the same moment, which filters out network trouble between one checker and your server. Confirmation over time filters out short failures on your side, such as restarts and deploys, which several locations would all see at once. Upcertain checks from one region (Seoul), so it confirms over time. #### Do failed checks that were not confirmed count as downtime? They do not open an incident and no one is alerted. The individual failed check is still recorded in the monitor's check log. #### What is a sensible default? One confirmation check after 15 seconds for most websites and APIs. Raise it for services with known restarts or deploys that fail for longer. ## Downtime alerts during deploys: why they happen and how to stop them Source: https://upcertain.com/learn/deploy-false-alarms If your monitoring alerts every time you ship, people learn to ignore it, and then they ignore the real outage too. Deploy-time failures are predictable, which makes them easy to handle. ### Why deploys fail health checks - The old process stops before the new one is ready. A single-instance app restarts, and requests in between get a 502 from the proxy or a connection refused. - The load balancer is slower than the app. New instances are marked healthy only after a few passing health checks, and old ones are drained, so for a moment there is nothing healthy behind the balancer: 503. - Warm-up. The new process answers, but the first requests time out while caches fill, connections open or code compiles. - Migrations. A schema change locks a table and requests that touch it fail until it finishes. All of these end on their own, usually within a minute or two, and they repeat on every deploy. That pattern is what to design the monitoring around. ### A worked example Suppose a service returns 503 for between 45 and 90 seconds on each deploy, several times a day, and is checked every 30 seconds. With no confirmation, nearly every deploy opens an incident and posts to Slack. With one confirmation check after 15 seconds, most deploys still do, because the failure lasts far longer than 15 seconds. Set three confirmation checks 30 seconds apart and the failure has to last about 90 seconds before an incident opens. Deploys that recover within that window pass silently; a real outage still alerts within about two minutes of starting. If deploys sometimes run longer, four checks (two minutes) gives more margin at the cost of thirty more seconds before a real outage is reported. Setting | Deploy noise (45 to 90 s of 503) | Real outage alerted after No confirmation | Alert on almost every deploy | about 15 to 30 s 1 check after 15 s | Alert on almost every deploy | about 30 to 45 s 3 checks, 30 s apart | Deploys up to about 90 s stay quiet | about 2 min 4 checks, 30 s apart | Deploys up to about 2 min stay quiet | about 2.5 min ### Fixes on the monitoring side 1. Measure the deploy failure. Look at a few deploys in the monitor's check log and note how long the failures last. 2. Set the confirmation window just above it. See confirmation checks for the arithmetic. 3. Use maintenance windows for long, planned work such as a database upgrade. Time inside the window is shown as maintenance, not downtime. 4. Delay slow channels, not fast ones. Keep the on-call Slack channel immediate and delay email to a wider group by a few minutes. 5. Do not slow the interval to hide noise. A 5-minute interval misses most deploy failures by luck, but it also takes up to 5 minutes to notice a real outage and still alerts when a check lands in a deploy. ### Fixes on the application side - Run at least two instances and replace them one at a time. - Add a readiness check so the load balancer sends traffic only to instances that can serve it, and drain connections before stopping old ones. - Point the uptime monitor at a page that exercises the real path (or a /health endpoint that checks the database), not at a static file a CDN would serve anyway. - Run long migrations in steps that do not lock hot tables. The monitoring fixes keep your team's attention for real problems. The application fixes remove the minute of errors your users still see during each deploy. Do both. #### Can I pause monitors from my deploy pipeline instead? You can pause and resume monitors through the REST API or the MCP server. Confirmation is simpler and does not depend on the pipeline remembering to resume them. #### Will deploy failures still show on my status page? Failures that never become incidents do not appear on the status page. Short incidents that do open can be folded into one line per day. ## How often should you check uptime? 30 seconds, 1 minute or 5 minutes Source: https://upcertain.com/learn/check-interval The check interval decides two things: how long an outage runs before you know, and whether a short outage is seen at all. Here is what each common interval buys you. ### Time to notice An outage starts at a random moment between two checks. On average the next check comes half an interval later, at worst a whole interval later. Confirmation checks then add their own delay. Interval | Average time to the first failed check | Worst case 30 s | 15 s | 30 s 1 min | 30 s | 1 min 5 min | 2 min 30 s | 5 min 30 min | 15 min | 30 min ### Outages you never see A check sees an outage only if it runs while the outage is happening. If an outage is shorter than the interval, whether any check lands inside it is a matter of chance: Outage length | Checked every 30 s | Every 1 min | Every 5 min | Every 30 min 30 s | always | 1 in 2 | 1 in 10 | 1 in 60 1 min | always | always | 1 in 5 | 1 in 30 2 min | always | always | 2 in 5 | 1 in 15 5 min | always | always | always | 1 in 6 With a 5-minute interval, most 1- and 2-minute outages pass unnoticed. That can look like better uptime, but your users still saw the errors. If short outages matter, for example on a checkout or a login, use a short interval and let confirmation checks decide which failures are worth an alert. ### Which interval for what - 30 seconds: revenue paths, public APIs, login, anything with an SLA. You hear within about a minute. - 1 minute: most production websites and internal tools people rely on during the day. - 5 minutes: marketing pages, documentation, staging and side projects. - 30 minutes to 24 hours: things that change slowly, such as a certificate on a rarely used host or a page you only need to know is still there. ### What a short interval costs - Load. One request every 30 seconds is 2,880 a day. That is nothing for most sites, but point the check at a lightweight health endpoint rather than a heavy page. - Noise, without confirmation. More checks see more blips. Pair a short interval with one or more confirmation checks. - Plan limits. In Upcertain the Basic plan checks as often as every 60 seconds; Team and Business as often as every 30 seconds. See pricing. - Uptime targets. The faster you notice, the more of your downtime budget is left for fixing. At 99.9% a month allows 43 minutes in total; see what 99.9% uptime means. ### Intervals available in Upcertain 30 seconds, 1 minute, 5 minutes, 30 minutes, 1 hour, 12 hours and 24 hours, set per monitor. Heartbeat monitors work the other way round: your job reports in, and you set how often it should. #### Is a 1-second or 10-second interval better still? Faster checks notice sooner, but below about 30 seconds the time spent confirming the failure and getting a person to act dominates. Upcertain's shortest interval is 30 seconds. #### Does a short interval count against a monitor limit? No. Plans limit the number of active monitors and the shortest interval, not the number of checks. ## Dead man's switch monitoring for scheduled jobs Source: https://upcertain.com/learn/dead-mans-switch-monitoring Most monitoring asks "are you there?" A dead man's switch works the other way round: it raises the alarm when something stops telling it "I am still here". ### Where the name comes from A train driver's dead man's switch stops the train unless the driver keeps pressing it. Nothing has to go wrong in a visible way: the absence of the signal is the alarm. Software borrowed the idea for work that has no address to check, such as cron jobs, backups, queue consumers and data imports. ### Why ordinary uptime checks miss these failures An HTTP check can tell you a website answers. It cannot tell you that last night's backup ran, because a job that never started produces no error, no log line and nothing to request. The failure is silence, and silence is exactly what a dead man's switch watches for. - A server is rebuilt and the crontab is not copied over. - A worker crashes and the process manager gives up restarting it. - A script starts failing on a full disk or an expired credential, so it exits before doing its work. - A platform's scheduled function is paused after a billing change or a deploy. ### How it works 1. You create a monitor with an expected period: how often the job should run. 2. The job calls the monitor's unique URL when it finishes successfully. 3. If no call arrives within the period plus a grace time, the monitor opens an incident and alerts you. 4. The next successful call resolves it. In Upcertain this is a heartbeat monitor, with periods from 30 seconds to 30 days and a grace time of up to a day. Setup snippets for cron, Node.js, Python, PHP and GitHub Actions are in the heartbeat guide. ### Choosing the period and grace Job | Period | Grace | Why Queue worker reporting every minute | 1 min | 1 to 2 min | A worker loop is steady; alert quickly Sync every 15 minutes, runs 1 to 5 minutes | 15 min | about 6 min | Covers the longest normal run Hourly GitHub Actions workflow | 1 h | 15 to 30 min | Scheduled workflows can start late Nightly backup, 20 to 50 minutes | 24 h | about 1 h | Long and variable run time Monthly invoice run | 30 d | 1 d | Rare job; a day's slack is fine Grace should cover the longest normal delay before the job starts plus its longest normal run time. Too little, and a slow night pages someone; too much, and you hear late. Start generous, look at a week of real arrivals and tighten it. ### Report success, not just existence Call the URL at the end of the job, and only when it succeeds. In a shell that is job.sh && curl .... A heartbeat sent at the start proves the job began, not that the backup was written. If you also want to know about failures immediately rather than at the deadline, have the job call your error tracker on failure; the heartbeat covers the case where nothing runs at all. ### Other uses - Network reachability from inside. A machine on a private network that pings out every minute tells you it is up and online, even though nothing can reach it from outside. - End-to-end pipelines. The last step of a data pipeline reports in, so a failure anywhere upstream shows up as a missing heartbeat. - Third-party schedulers. Jobs run by a platform you do not control can still report to you. #### Is a dead man's switch the same as heartbeat monitoring? Yes. Heartbeat monitoring, push monitoring, cron monitoring and dead man's switch all describe a monitor that expects a regular signal and alerts when it stops. #### What if the job runs twice? Extra calls are harmless. The monitor only cares that at least one call arrived within each period. ## What 99.9% uptime means in minutes Source: https://upcertain.com/learn/what-does-99-9-uptime-mean Uptime percentages sound alike and are not: 99.9% allows ten times the downtime of 99.99%. Here is what each common target allows per day, week, month and year. ### The downtime each target allows Uptime | Per day | Per week | Per 30-day month | Per year 99% | 14 m 24 s | 1 h 40 m 48 s | 7 h 12 m | 3 d 15 h 36 m 99.5% | 7 m 12 s | 50 m 24 s | 3 h 36 m | 1 d 19 h 48 m 99.9% | 1 m 26 s | 10 m 5 s | 43 m 12 s | 8 h 45 m 36 s 99.95% | 43 s | 5 m 2 s | 21 m 36 s | 4 h 22 m 48 s 99.99% | 8.6 s | 1 m 0.5 s | 4 m 19 s | 52 m 34 s 99.999% | 0.9 s | 6 s | 25.9 s | 5 m 15 s The formula: allowed downtime = (1 - target) x length of the period. A year here is 365 days and a month 30 days. Using the average calendar month (30.4 days) gives slightly more: 43 m 50 s at 99.9%. Try other targets and periods in the uptime calculator. ### Reading the table - 99.9% ("three nines") allows one 43-minute outage a month, or a two-minute blip every day. It is a common target for business software and many SLAs. - 99.95% halves that: about 22 minutes a month. - 99.99% ("four nines") allows about four minutes a month. Detecting and confirming an outage can use up a good part of that before anyone starts fixing it. - 99.999% allows about five minutes a year. It needs automatic failover; no person can respond that fast. ### Measured uptime depends on how you measure The same service can report different uptime depending on the monitor: - Check interval. A monitor checking every 5 minutes misses most 1- and 2-minute outages, so it reports higher uptime than one checking every 30 seconds. See how often to check. - What counts as down. A slow page, a 200 with an error message on it, or one region failing may or may not count, depending on the check. - Maintenance. Many SLAs exclude scheduled maintenance. Upcertain counts time inside a maintenance window as maintenance, not downtime. - The period. 99.9% over a year allows a single eight-hour outage that would break a monthly 99.9% target ten times over. ### Setting a target you can keep 1. Measure first. Run a monitor for a month and see what you actually achieve, including deploys. 2. Set an internal target above what you promise customers, so a bad month is a warning rather than a breach. 3. Budget the downtime. At 99.9% you have 43 minutes a month for incidents and risky changes together. If deploys cost a minute each, twenty deploys a month use half the budget. 4. Publish it honestly. A status page with 90 days of history shows customers the real number. ### Uptime is not the whole story Two services with 99.9% uptime can feel very different: one has a single 43-minute outage a month, the other a 90-second blip every night. Uptime also says nothing about speed; a page that takes twelve seconds to load is "up". Watch the number of incidents and how long they last as well as the percentage. #### How much downtime is 99.9% per year? 8 hours, 45 minutes and 36 seconds in a 365-day year. #### How much downtime is 99.9% per month? 43 minutes 12 seconds in a 30-day month, or about 43 minutes 50 seconds in an average calendar month. #### Is 99.9% uptime good? For most business websites and SaaS products it is a reasonable, common target. Payment systems and infrastructure other companies build on usually aim higher. ## What is uptime monitoring? Source: https://upcertain.com/learn/what-is-uptime-monitoring Uptime monitoring is a service that checks your website, API or server from outside on a regular schedule, and tells you when it stops working, ideally before your customers do. ### How it works 1. You give the monitor something to check: a URL, a host, a port or a scheduled job. 2. It checks on an interval, such as every 30 seconds or every 5 minutes. 3. Each check passes or fails by a rule: the right status code, a phrase on the page, an open port, a valid certificate, a heartbeat that arrived on time. 4. When a failure is confirmed, it opens an incident and alerts the people responsible. 5. When checks pass again, it records the recovery and the downtime. ### Kinds of checks Check | Answers HTTP | Does the URL answer with an acceptable status? Keyword | Does the page say what it should, or something it should not? Ping | Is the host reachable? Port | Does a service such as a mail server or database accept connections? SSL certificate | Is the certificate valid, and when does it expire? Heartbeat | Did the scheduled job report in on time? ### Why monitor from outside Logs and server metrics describe what your server sees. Uptime monitoring describes what a visitor sees: DNS, certificates, the network, the load balancer and the application all have to work for a check to pass. It catches the failures that internal tools are blind to, including the server being completely gone. ### What it does not tell you - Why something failed. A monitor records the symptom, such as an HTTP 503 or a timeout; your logs explain the cause. - Everything in between checks. A failure shorter than the interval can fall between two checks. See how often to check. - Every user's experience. A check from one place can pass while users elsewhere have trouble, and the reverse. - Whether a multi-step flow works. Signing up or paying needs browser-based transaction checks, which are a different kind of tool. ### False alarms and how to avoid them A single failed request is often noise: a dropped packet or a restarting container. Good monitoring confirms a failure before alerting, by checking again a few seconds later or from another location. Without that, teams quickly learn to ignore alerts. See confirmation checks. ### Where the alerts go Email is the baseline. Most teams add the chat tool they work in, such as Slack or Microsoft Teams, and a webhook into their own tools. On-call teams connect a paging service that phones the person on duty. ### Status pages: telling customers Monitoring tells your team. A status page tells your customers, built from the same checks: what is up, what is down, and what happened recently. It saves your support team from answering the same question many times during an outage. ### Getting started 1. Monitor the page customers use most: the home page, the app's login, the public API. 2. Add a keyword check for pages that can fail with status 200. 3. Add heartbeats for backups and scheduled jobs. 4. Send alerts to the people who can fix things, and confirm failures before anyone is woken. #### Is uptime monitoring the same as application performance monitoring? No. Application performance monitoring (APM) instruments your code from inside and explains slow requests. Uptime monitoring checks from outside whether the service works at all. Most teams use both. #### How often should a website be checked? Every 30 seconds to 1 minute for anything customers pay for or log in to; every 5 minutes for content sites. The interval guide explains the trade-off. ## Cron job monitoring: catching jobs that silently stop Source: https://upcertain.com/learn/cron-job-monitoring Cron jobs run backups, send invoices, sync data and clean up. When one stops, nothing breaks loudly. You find out days later, when the data is missing. ### Why cron failures go unnoticed - cron itself reports nothing. By default output goes to local mail that nobody reads, or nowhere. - A job that never starts writes no error. A deleted crontab, a server rebuilt from an old image or a stopped scheduler produces silence. - Failures inside the job are easy to swallow. A script that ignores a failed command exits 0 and looks fine. - Containers and serverless move the schedule. Jobs scheduled by Kubernetes, a PaaS or GitHub Actions can be paused or skipped by the platform. ### Four ways to monitor scheduled jobs Approach | Catches | Misses Log or email the output | Errors the job reports | Jobs that never start; output nobody reads Error tracking in the job | Exceptions inside the job | Jobs that never start Check the result (a fresh file, a new row) | Missing results | Needs custom code per job Heartbeat (dead man's switch) | Jobs that do not run or do not finish | Wrong results from a job that succeeds Heartbeats are the only approach that catches the commonest failure, the job not running at all, without writing custom checks. Combine them with error tracking for the failures a job can report itself. ### How heartbeat monitoring works The job calls a unique URL when it finishes successfully. The monitor knows how often that should happen. If a call does not arrive within the period plus a grace time, it alerts. In a crontab, it is one extra command after &&: 0 3 * * * /opt/jobs/export.sh && curl -fsS -m 10 --retry 3 https://upcertain.com/api/heartbeat/ Snippets for Node.js, Python, PHP, Laravel and GitHub Actions are in the heartbeat setup guide. ### Choosing the period and grace The period is how often the job should run. The grace covers the normal variation in start time and run time; a nightly export that takes 10 to 40 minutes needs roughly 45 minutes of grace. Start generous, then tighten it after a week of real data. The dead man's switch guide has a table of examples. ### Make the job honest - Start shell scripts with set -euo pipefail so a failed step fails the script. - Send the heartbeat at the end, and only on success. - Give the job a timeout, so a hung job stops and the missing heartbeat alerts you. - Keep one heartbeat per job, so the alert names the job that stopped. ### In Upcertain Heartbeat monitors take periods from 30 seconds to 30 days and grace up to a day. Missed heartbeats open incidents and alert the same channels as your website monitors, and the next call resolves them. #### Should I send a heartbeat at the start of the job as well? Usually not. A start ping proves the job began, not that it finished. Send one heartbeat at the end, on success, and rely on the deadline to catch jobs that never start, hang or fail. #### What about jobs that run every minute? Call the heartbeat from each run; Upcertain treats repeated calls within 5 seconds as one, and the shortest period is 30 seconds. ## How to monitor your MCP server's uptime Source: https://upcertain.com/learn/monitor-mcp-server-uptime If customers connect Claude, ChatGPT or Cursor to your product over the Model Context Protocol, your MCP server is production infrastructure. When it is down, their agents silently lose access. ### What to monitor - The MCP endpoint, for example https://api.example.com/mcp, which clients connect to over HTTP. - The sign-in pieces, if you use OAuth: the authorisation server metadata and the token endpoint. - The certificate, because clients refuse invalid ones without telling the user much. - The services behind the tools, which are usually your existing API. ### Expect a 401 A remote MCP server that requires sign-in answers an unauthenticated request with HTTP 401 and a WWW-Authenticate header that tells the client where to sign in. That 401 is the healthy answer. Monitor the endpoint with an HTTP check whose expected status is 401: a 401 means up and still protected, while a 5xx or a timeout means down. A 200 means authentication has been switched off, which you also want to know. URL: https://api.example.com/mcp Method: GET Expected status: 401 Interval: 1 min Confirmation: 1 check after 15 s ### Check the sign-in metadata OAuth-based MCP clients first fetch metadata documents to find your authorisation server. Add a keyword monitor on the protected-resource metadata URL that must contain your issuer address, for example "authorization_servers". If that document breaks, new users cannot connect even though the endpoint answers. URL: https://api.example.com/.well-known/oauth-protected-resource Mode: must contain Keyword: "authorization_servers" ### Going deeper than reachability An endpoint that answers 401 can still have broken tools. For a deeper check, expose a small health endpoint that exercises what the tools depend on (the database, the upstream API) and monitor it over HTTP with a keyword. Keep it free of customer data. ### Alerting and communicating - Route MCP alerts to the team that owns the API, since the cause is usually there. - Put the MCP server on your status page as its own service, so customers whose agents stopped working can see why. - Watch your certificate: SSL monitoring warns weeks before expiry. ### The other direction Monitoring works the other way round as well. Upcertain has its own MCP server, so Claude or Cursor can ask which monitors are down and read incidents, including those of your MCP server. #### Can I monitor an MCP server that runs locally over stdio? No. Local stdio servers run inside the client on the user's machine and have no address to check. Uptime monitoring applies to remote MCP servers reached over HTTP. #### Should the monitor sign in to the MCP server? Usually not. Checking that the endpoint answers 401 and that the sign-in metadata is served covers reachability without storing a long-lived token in the monitor. For a deeper check, monitor a separate health endpoint. #### How often should an MCP endpoint be checked? As often as the API behind it, because agents depend on both. If agents use your product during working hours, every 30 seconds to 1 minute keeps detection within about a minute. ## SSL certificate expiry: why it still causes outages Source: https://upcertain.com/learn/ssl-expiry-monitoring An expired certificate is one of the most avoidable outages there is, and it still happens to large companies. Automation made it rarer and quieter, not impossible. ### What happens when a certificate expires Browsers show a full-page warning instead of your site, and most visitors leave. API clients refuse to connect and fail with TLS errors, often far from where the cause is obvious. Mobile apps that pin certificates stop working until the certificate is fixed or the app is updated. ### Why automated renewals still fail - Validation breaks. The issuer must reach your server or DNS to renew. A changed DNS provider, a new firewall rule or a moved load balancer can block it. - The new certificate is not deployed. It renewed on one machine, but the load balancer, CDN or another server still serves the old one. - The renewal job stopped. A cron job or timer on a rebuilt server is a silent failure like any other. - Forgotten hosts. An old subdomain, a mail server or an internal tool that someone set up by hand years ago. - Rate limits and account problems at the certificate issuer. ### How far ahead to be warned Warning | Why 30 days | Time to notice that automation failed and fix it calmly 14 days | A reminder if the first one was missed 7 days | Escalate: renew by hand if needed 1 to 3 days | Last call, for teams with manual renewals Certificates from automated issuers are often renewed with about a month left, so a warning at 30 days or less fires only when automation has failed. If yours renew earlier or later, move the warnings to match. ### Check more than the date - Hostname: the certificate must cover the exact name, including www. - Chain: a missing intermediate certificate works in some browsers and fails in API clients. - What is actually served: check the public address, not the file on disk, so you see what visitors get. ### Who should get the warning Send expiry warnings to whoever can renew certificates, which may not be the person on call for outages. In Upcertain each alert channel chooses whether it receives SSL events, so certificate warnings can go to one email address while outages go to Slack. ### In Upcertain Every HTTPS monitor checks expiry, hostname and chain, and warns 30, 14 and 7 days ahead by default; you can choose up to five days between 1 and 90. Separate SSL monitors watch hosts you do not otherwise check. Setup is in the SSL monitor docs. #### Will my certificate issuer warn me before expiry? Do not rely on it. Reminder emails, where an issuer sends them, go to whatever address was registered, often a colleague who has since left. A monitor that checks the certificate your server actually serves is the safer source. #### Why do shorter certificate lifetimes matter? The shorter a certificate's life, the more often it renews, and every renewal is another chance for automation to fail. Short lifetimes make expiry monitoring more useful, not less. ## How to create a status page customers will trust Source: https://upcertain.com/learn/how-to-create-a-status-page A status page is a promise: when something breaks, this is where you will tell the truth. Built well, it cuts support load during outages and earns trust between them. ### 1. Decide who it is for A public page for all customers shows the services they use, in their language. An internal page for staff can show more detail. A page for one large customer can be password-protected. Many teams need more than one. ### 2. Choose what to show - List services as customers see them: "Website", "Web app", "API", "Payments". Not prod-web-2. - Group them into a few sections, such as Platform and Integrations. - Show each service's current state and recent history. Ninety days of daily bars is a common format. - Hide internal URLs and hostnames if they reveal anything you would rather keep private. ### 3. Connect it to real monitoring A status page updated by hand is out of date exactly when it matters: during the outage, when everyone is busy fixing. Build it from your monitors, so the state changes on its own and you only write the explanation. ### 4. Put it on your own domain Use a subdomain such as status.yourcompany.com, hosted separately from your main infrastructure, so it stays up when your product does not. Customers trust the address, and you can print it in docs and error messages. The custom domain guide shows the DNS record. ### 5. Write updates people can use 1. Acknowledge quickly. "We are investigating errors on the API" within minutes beats a perfect message an hour later. 2. Say what users notice, not your internals: "Payments fail at checkout", not "Database primary failover". 3. Give the next update time and keep it. 4. Close it properly: what happened, how long it lasted, what you changed. ### 6. Let people subscribe Email subscriptions turn the page from something people check into something that tells them. See subscribers. ### 7. Announce maintenance ahead Planned work belongs on the page days in advance, so customers can plan around it. Scheduled maintenance windows do this and keep the time out of your uptime figures. ### 8. Be honest about short outages Listing every 40-second blip buries what matters; hiding them erodes trust. Upcertain folds brief outages into one line a day and still counts them in uptime. The reasoning is in brief outages on status pages. ### Building it in Upcertain Create a status page from your monitors, pick the sections and public names, upload a logo and choose light or dark. Pages can be public, password-protected or private. See status pages and Upcertain's own status page for an example. #### Should a status page show uptime percentages? Yes, if they come from real monitoring. They show long-term reliability at a glance, and visitors can see the history behind them. #### Where should the status page be hosted? Away from your own infrastructure, so an outage of your servers does not take the status page down with them. A hosted status page on your own subdomain gives you both. ## Incident response for small teams Source: https://upcertain.com/learn/incident-response-small-teams Large companies have incident commanders and runbooks. A team of five has whoever sees the alert first. A small amount of process, agreed before the outage, makes that work. ### Before anything breaks - Agree who responds when. Even without a formal rotation, write down who covers evenings and weekends this week. - Route alerts to people who can act. Each service's alerts go to its owners' channel; managers can get a delayed email instead. - Cut the noise first. A team that gets false alarms stops reading alerts. Confirm failures before alerting; see confirmation checks. - Have a status page ready, with its address in your docs and support replies. - Keep a short note per service: where it runs, how to restart it, who to call at the provider. ### When the alert fires 1. Acknowledge. It tells everyone that someone is on it and stops repeat alerts. In Upcertain the alert links straight to the incident. 2. Check the scope. Is it one service or many? Several monitors failing at once usually means a shared dependency. 3. Tell customers if they are affected. A short status update within 10 to 15 minutes, even if you do not know the cause yet. 4. Fix or mitigate. Roll back the last deploy first if it is a likely cause; investigate after service is restored. 5. Write notes as you go in the incident: what you tried and what changed. You will not remember later. ### Who does what Role | Small-team version Responder | Whoever acknowledged; works on the fix Communicator | A second person, if there is one, who posts updates and answers support Decision-maker | The responder, unless they ask for help Splitting fixing from communicating is the one role change that helps even a two-person team: the person fixing should not also be writing customer updates. ### After it is resolved 1. Post a closing update on the status page. 2. Within a few days, write a short review: what happened, how long, what users saw, what made it worse or better, and one or two changes. 3. Make the changes small enough to actually do: an extra monitor, a better alert, a runbook line. ### Measure only what you will use Two numbers are enough to start: how long until someone acknowledged, and how long until it was resolved. Upcertain records both on every incident, and exports them as CSV. See incidents. ### When to add more process Add a formal on-call rotation and paging when outages outside working hours start costing real money, or when the same person keeps getting woken. Until then, clear ownership, quiet alerts and an honest status page cover most of what matters. #### Do we need a formal post-mortem for every incident? No. Write one for incidents customers noticed or that took longer than an hour. For the rest, a line in the incident's notes is enough. #### How quickly should we update customers? Within 10 to 15 minutes of confirming customers are affected, then at the interval you promise in that first message. ## How to monitor website uptime, step by step Source: https://upcertain.com/learn/how-to-monitor-website-uptime Setting up uptime monitoring takes an afternoon. Doing it so it catches real problems without crying wolf takes a few decisions. Here they are in order. ### 1. List what users depend on Start from the user's side, not the server's. Write down the pages and endpoints that people use: the home page, sign-in, the main app page, checkout, the public API, and the jobs that send email or invoices. That list is your first set of monitors. ### 2. Choose the right check for each What | Check A page that must load | HTTP, expecting 200 A page that can fail while returning 200 | Keyword: a phrase that only appears when it works An API | HTTP on a health endpoint that checks the database A server or service without a web page | Ping or port A certificate | Comes with every HTTPS check A scheduled job | Heartbeat ### 3. Pick intervals Every 30 seconds to 1 minute for anything people pay for or sign in to; every 5 minutes for content pages; less often for things that change slowly. A long interval misses short outages entirely; see check intervals. ### 4. Confirm before alerting Set at least one confirmation check, so a single failed request is checked again before anyone is told. For services whose deploys fail for a minute, set enough re-checks to outlast them. See confirmation checks. ### 5. Send alerts to the right people - Each service's alerts go to the team that owns it, in the chat tool they use. - Email for people who need to know but not act. - Reminders only on critical services, so an unacknowledged outage keeps reminding people. ### 6. Tell customers Publish a status page built from the same monitors, on a subdomain such as status.yourcompany.com. Link it from your help pages and error messages. ### 7. Review after a month Look at every alert you received. For each one nobody needed, change a setting: more confirmation, a longer interval, a different channel or a better keyword. For each outage you heard about late, shorten the interval or add the check that would have caught it. ### Doing it in Upcertain Guided setup takes one website and creates its checks in one step; CSV import takes a whole list. Six monitor types, confirmation per monitor, six alert channels and status pages are on every plan. Start with the website monitoring overview. #### Do I need to install anything? No. Uptime checks run from outside, like a visitor; only heartbeat monitors need a line added to your job. #### What should I name monitors? After what users see, such as "Checkout page" or "Public API", not the server name. The name appears in every alert and on status pages. #### How many monitors does a typical website need? Three to five: the home page, a keyword check on the most important page, the API or app, and a heartbeat for each scheduled job that matters. #### Should I monitor from several locations? It helps tell regional network problems from real outages. Single-region monitoring still catches the most common failures: crashes, bad deploys, full disks and expired certificates. ## How to check if a website is down, for everyone or just you Source: https://upcertain.com/learn/how-to-check-if-a-website-is-down A site will not load. Before blaming the server, find out whether it is down for everyone or only for you. Each step below takes under a minute. ### 1. Rule out your own connection - Open another site you know works. - Try the site on mobile data instead of Wi-Fi, or from a different network. - Try a private window, which skips your cache, cookies and most extensions. ### 2. Check the site's status page Many services publish one, often at status.. If they report an incident, you have your answer and their timeline. ### 3. Ask the network directly # Does the name resolve? dig +short example.com # Does the server answer, and with what status? curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com # Is the certificate valid, and until when? echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates What you see | Likely meaning dig prints nothing | DNS problem: the name does not resolve curl times out | Server or network down, or a firewall blocking you curl prints 5xx | The server answers but the application is failing curl prints 200 but the page is broken | A front-end or content problem Certificate dates in the past | An expired certificate: browsers show a warning ### Common causes, quickest to check first - A deploy in the last hour: roll it back or check its logs. - The hosting provider or CDN: check their status pages. - DNS: a changed or expired record, or an expired domain. - The certificate: expired, or not covering the name you visit. - Resources: a full disk, an exhausted database connection pool or a memory limit. ### 4. Check from somewhere else Ask a colleague in another place or network to load the site, or run the curl command from a server you have elsewhere. If it works there and not for you, the problem is between you and the site. ### If it is your site 1. Check your hosting provider's and CDN's status pages. 2. Look at the last deploy: roll it back if the timing matches. 3. Check the certificate and the domain's DNS records. 4. Post a short update on your status page so customers stop wondering. ### Why a one-off check is not monitoring Checking by hand tells you about now. It does not tell you when the problem started, whether it happened last night while you slept, or that the certificate expires next week. Monitoring checks on a schedule, confirms failures, alerts the right people and keeps the history. See what uptime monitoring is. #### Can a site be down only in some countries? Yes. A CDN or network problem can affect one region while the rest of the world loads the site normally. #### Why does a site work on my phone but not my laptop? Usually a local cause: a DNS cache, a browser extension, a VPN or a network filter. Try a private window, flush the DNS cache or switch networks. #### What does a 503 error mean? The server is reachable but cannot handle the request right now, often during a deploy, an overload or maintenance. ## Uptime monitoring pricing compared: what you pay for Source: https://upcertain.com/learn/uptime-monitoring-pricing-compared Uptime monitoring prices look similar until you add your team, your status page and the interval you need. Here is how the main tools charge, from their own pricing pages, read on 25 October 2026. ### Four pricing models Model | Examples | Watch for Tiers by number of monitors | UptimeRobot, StatusCake, Pulsetic, Hyperping | Seat limits and which tier unlocks 30-second checks Per monitor plus per user | Cronitor ($2 per monitor, $5 per user a month on Business) | Costs grow with both monitors and people Per site | Oh Dear (from €15 a month for 2 sites) | A site with many endpoints counts once Per responder or add-on | Better Stack (responder licence $34 a month; status page add-ons) | Password protection and white labelling priced per page ### Entry options and 30-second checks Tool | Entry option | Where 30-second checks start UptimeRobot | Free: 50 monitors, 5 min | Team: $35 a month billed annually StatusCake | Free: 10 monitors, 5 min | Business: $66.66 a month billed annually Hyperping | Free: 20 monitors, 5 min | Not stated on its pricing page; paid plans from $24 a month billed annually Pulsetic | Free: 10 monitors, 5 min | Team: $19 a month (discounted from $39 when read) Cronitor | Hacker: 5 monitors, 5 min | Business: $2 a month per monitor OpenStatus | Free: 1 monitor, 10 min | Not stated on its pricing page; paid plans from $30 a month Prices change. Each comparison page links its source and the date it was read; check the vendor's page before buying. ### What adds up - Seats. Several tools include 3 to 10 seats and charge per extra user. - Status page extras. Password protection, removing branding, extra pages and subscribers are add-ons on some tools. - SMS and phone alerts. Usually credits or per-message fees. - Faster intervals. Often the reason to move up a tier. ### Free plans and their limits Several tools have a no-cost tier, usually with 5- or 10-minute checks, a single seat or a basic status page. That suits side projects. For a business site, the 5-minute interval is the limit to watch: it misses most short outages. See check intervals. ### Annual or monthly billing Most tools discount annual billing, often by about two months' worth. The tables above show the price each vendor leads with; where it is the annual rate, the row says so. Compare like with like before deciding. ### How to compare for your own case 1. Count your monitors, including APIs, ports and scheduled jobs. 2. Decide the interval each needs. 3. Count who needs a login and who only needs alerts. 4. List status page needs: custom domain, password, subscribers. 5. Price each tool with those numbers, not with its headline price. ### Where Upcertain fits Upcertain is in early access: billing is not enabled and plans are assigned from the account. Team includes 100 monitors at 30-second checks, unlimited members, unlimited status pages with custom domains and password protection, and MCP. See pricing and the comparison pages. #### Is the cheapest plan the best value? Only if its interval, seats and status page cover what you need. Price your own list of monitors and people on each tool. ## Monitoring from one region: what checks from Seoul mean for you Source: https://upcertain.com/learn/monitoring-from-seoul Upcertain runs its checks from one place: AWS in Seoul. That is a deliberate trade-off, and you should know what it means before you rely on it. ### What single-region monitoring catches Most outages happen at the service itself: the application crashes, a deploy breaks it, the database is full, a certificate expires, DNS records change. A checker in any one region sees all of these, because the service fails for everyone. ### What it can miss - Regional network problems. If a network route between Seoul and your server fails while the rest of the internet is fine, Upcertain sees a failure your users elsewhere may not. Confirmation checks help, because routing problems are often brief. - Regional outages elsewhere. If your CDN fails only in Europe, a check from Seoul may pass while European users see errors. - Geo-specific content. Sites that serve different pages by country are checked as seen from Korea. ### Response times include distance Each check records the time to the first response. A server in Europe or the Americas answers a check from Seoul more slowly than a nearby visitor sees, because the request travels further. Compare a monitor's response times with its own history, not with numbers from tools that check from closer by. ### Timeouts and confirmation for distant servers Set each monitor's timeout well above its normal response time, so a slow but working answer is not counted as a failure. Keep at least one confirmation check, so a brief routing problem between Seoul and the server does not open an incident. Most regional network problems last seconds, not minutes. If a distant monitor fails often while your users report no problems, check its history in the incident list. A pattern of short failures at the same hour usually points at a network route, not your service. ### Who it suits - Teams in Korea, Japan and the rest of Asia-Pacific whose users are nearby. - Services whose failures are mostly on the service itself, which is most of them. - Teams that want fast, confirmed alerts more than a map of regional availability. ### When to add another view If your users are concentrated far from Seoul and regional problems matter to you, add a second monitor from a tool that checks from their region, or a heartbeat from a small job running near your users. The comparison pages list which tools check from several regions. ### Where your data lives Account data is stored in a Supabase Postgres database in the same region, Seoul (ap-northeast-2). See the privacy policy. #### Can I see where a check came from? Every check runs from Seoul, so there is nothing to choose or compare between locations in the app. #### Will Upcertain add more regions? Checks run from Seoul today. This page will change if that does. #### Does a distant server cause false alarms? Not by itself. Distance adds response time, not failures; set the timeout well above the normal response time and keep at least one confirmation check. ## Upcertain and Better Stack compared Source: https://upcertain.com/compare/better-stack Better Stack is a broad observability platform: uptime, on-call, logs, traces and more. Upcertain does one part of that, uptime monitoring with incidents and status pages, for teams that want only that part. ### The short version - Pick Better Stack if you want phone and SMS alerts, on-call schedules, checks from several locations, browser (Playwright) transaction checks, or logs and tracing in the same product. - Pick Upcertain if you want uptime checks, confirmed incidents, team alerts and status pages without per-responder licences or paid add-ons for status page options, and an MCP server your whole team can connect to. ### Side by side | Upcertain | Better Stack Monitor types | HTTP, keyword, ping, port, SSL, heartbeat | HTTP, keyword, ping, TCP and UDP ports, SSL, DNS, domain expiry, mail servers, heartbeats, Playwright transactions Fastest check | 30 s (Team and Business), 60 s (Basic) | Up to 30 s Check locations | One region (Seoul) | Multiple locations Confirming a failure | 0 to 5 re-checks, 15 to 120 s apart, per monitor | Multi-step incident verification Alerts | Email, Slack, Discord, Microsoft Teams, Google Chat, signed webhooks | Email, Slack, Teams, webhooks, push, and phone and SMS for responders On-call scheduling | No | Yes, for responder licences Status page password protection | Included | $50 per page a month Remove the "Powered by" footer | Included on Team and Business | $250 per page a month Custom domain for status pages | Team and Business | Branded status.yourdomain.com MCP server | Yes, for any member, OAuth sign-in or API key | Yes, listed with its AI SRE features Prices | Early access: plans assigned without billing | Free tier; responder licence $34 a month ($29 billed annually) Better Stack's figures come from its pricing page, read on 25 October 2026; check it for current prices. Upcertain's limits come from its plans. ### Where Better Stack does more Better Stack checks from several locations, which filters out network trouble between one checker and your server and shows regional outages. It calls and texts the person on duty, runs on-call rotations, and records browser transactions with Playwright. It also bundles logs, metrics, traces and error tracking. Upcertain does none of these. If you need them, Better Stack is the more complete tool. ### Where Upcertain is different - Status pages that explain outages. Incidents that start together show as one, with each service's own downtime, and brief outages fold into one line per day with their total. See status pages. - Status page options without add-ons. Password protection is part of every page, and Team and Business can hide the Upcertain footer link. On Better Stack those are $50 and $250 per page a month. - Confirmation you tune per monitor. Set how many re-checks and how far apart, per service, to match how long your deploys fail. See confirmation checks. - MCP for the whole team. Any member except notify-only can connect Claude, Cursor or another client with their own sign-in, read-only by default. See the MCP server. - Seats. Team and Business include unlimited members with roles. ### Moving from Better Stack 1. Export or list your monitors' URLs, intervals and expected status codes. 2. Import them into Upcertain with a CSV file (header columns or one URL per line, up to 200 rows at a time) or guided setup. 3. Add alert channels: Slack, Teams, Discord, Google Chat, email or webhooks. 4. Build the status page, then move your custom domain's CNAME to pages.upcertain.com (steps). 5. Run both tools side by side for a week before switching off the old monitors. #### Does Upcertain have a free plan like Better Stack? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. #### Does Upcertain call my phone? No. Upcertain alerts by email, chat tools and webhooks. If you need phone calls, Better Stack or a paging tool connected to an Upcertain webhook can do that. ## Uptime Kuma or a hosted monitor: how to choose Source: https://upcertain.com/compare/uptime-kuma Uptime Kuma is an open-source, self-hosted monitoring tool under the MIT licence, and a good one. The real question is not which is better but whether you want to run your monitoring yourself. ### What Uptime Kuma offers According to its README, Uptime Kuma monitors HTTP(S), TCP, HTTP keyword and JSON queries, WebSocket, ping, DNS records, push (heartbeat), Steam game servers and Docker containers. It checks as often as every 20 seconds and sends notifications through more than 90 services. It serves multiple status pages, which can be mapped to your own domains. You install it with Docker or Node.js on a server you run. ### What self-hosting involves - A server outside what it monitors. A monitor on the same machine or network as your app goes down with it, and cannot tell you so. - Watching the watcher. If the monitoring server stops, alerts stop with it. Someone has to monitor the monitor. - Updates and backups. Upgrades, database backups and security patches are yours. - HTTPS and domains for status pages. A reverse proxy and certificates for every status page domain. ### Side by side | Upcertain | Uptime Kuma Hosting | Hosted by Upcertain | Self-hosted (Docker or Node.js) Licence and cost | Early access, plans without billing | MIT licence; you pay for the server Monitor types | HTTP, keyword, ping, port, SSL, heartbeat | HTTP, TCP, keyword, JSON query, WebSocket, ping, DNS, push, game servers, Docker containers Fastest check | 30 s | 20 s Notifications | Email, Slack, Discord, Teams, Google Chat, signed webhooks | 90+ services Status pages | Custom domain with automatic HTTPS, password or private, subscribers, per-service downtime | Multiple pages, mapped to your domains Team members and roles | Owner, admin, editor, viewer, notify-only | Not in the README's feature list REST API and MCP | Yes | Not in the README's feature list Uptime Kuma's details come from its README on GitHub, read on 25 October 2026. ### When Uptime Kuma is the better choice - You need a monitor type Upcertain does not have, such as DNS records, Docker containers or game servers. - You must monitor services on a private network that nothing outside can reach. - You already run servers and like owning every part of your stack. - You need a notification service Upcertain does not support directly. ### When hosted is the better choice - You do not want monitoring to depend on a server you also have to keep alive. - Several people need their own logins with roles: owner, admin, editor, viewer or notify-only. - You want status pages on your domain without running a proxy, with subscribers and password protection. - You want AI agents to read your monitors over MCP or scripts to use a REST API. ### Using both You can keep Uptime Kuma inside your network for private services and use a hosted monitor for public endpoints and the status page. A heartbeat monitor in Upcertain can even watch the self-hosted monitor: have the Uptime Kuma server call the heartbeat URL every minute, and you hear if it stops. #### Can I import my Uptime Kuma monitors? List the URLs, one per line or in a CSV with columns such as type, URL and interval, and import them into Upcertain. Up to 200 rows are previewed and created at a time. ## Freshping has shut down: moving your monitors Source: https://upcertain.com/compare/freshping Freshping, Freshworks' free website monitor, was retired: free plan access ended on 6 March 2026 and no renewals were offered after that date. If you used it, your monitors need a new home. ### What happened Freshworks emailed Freshping users that it was retiring the product. Free plans could be used until 6 March 2026, and paid plans could not renew after that date. The Freshping website now redirects to Freshworks. ### What to rebuild - Checks: each URL with its interval and what counts as up. - Alert contacts: who was emailed and which chat tools were connected. - Status page: which checks it showed and the domain it used. ### Rebuilding in Upcertain 1. Create an account. New accounts start on the Basic plan: 10 monitors checked as often as every 60 seconds and one status page. 2. Put your URLs in a file, one per line, or as a CSV with header columns such as name,url,type,interval. Choose New monitor, then Import from CSV; every row is previewed before anything is created, up to 200 at a time. 3. Add alert channels in Settings, Alert channels: email, Slack, Microsoft Teams, Discord, Google Chat or webhooks. 4. Create a status page from the same monitors. On Team and Business, put it on your own domain (steps). 5. Add heartbeat monitors for scheduled jobs if you had no way to watch them before. ### What to rebuild, and where it goes What to rebuild | In Upcertain Website and API checks | HTTP and keyword monitors, plus ping, port, SSL and heartbeat Alert contacts | Email, Slack, Teams, Discord, Google Chat and signed webhooks A status page | Public, password-protected or private pages, custom domains on Team and Business Check intervals | Every 60 s on Basic, every 30 s on Team and Business ### Choosing intervals and confirmation Before copying your old intervals everywhere, sort your URLs by how much a short outage costs. Checkout, login and public APIs deserve the shortest interval your plan allows; documentation and marketing pages are fine every 5 minutes. Then decide how long a failure must last before anyone hears about it: one re-check after 15 seconds filters out dropped requests, while services with slow deploys may want three re-checks 30 seconds apart. How often to check has the numbers. ### Alerts that reach the right people In Upcertain each monitor picks alert channels, and each channel picks events: down, recovery and SSL expiry. Give each team its own channel, so the payments team does not hear about the blog. Add a delay on channels that only need to know about long outages. Set a repeat interval on critical monitors, so an unacknowledged incident keeps reminding people. People who only need to hear about outages can be notify-only contacts: they get email alerts and have no login. ### Things worth setting up this time - Confirmation checks, so one dropped request does not alert anyone. - Certificate expiry warnings, which come with every HTTPS monitor. - Separate channels per team, so alerts reach the people who own the service. #### Is Upcertain free like Freshping was? Upcertain is in early access: billing is not enabled and plans are assigned from the account. #### Can I keep my status page address? If your Freshping status page used your own subdomain, point that subdomain's CNAME at pages.upcertain.com and connect it to an Upcertain page on the Team or Business plan. ## Upcertain and UptimeRobot compared Source: https://upcertain.com/compare/uptimerobot UptimeRobot is one of the best-known uptime monitors, with a free plan and paid tiers from Solo to Enterprise. Here is where Upcertain differs, and where UptimeRobot offers more. ### The short version - Pick UptimeRobot if you want a free plan, checks from several regions, SMS and voice calls, a mobile app, UDP or DNS monitoring, or 15-second checks. - Pick Upcertain if you want 30-second checks and unlimited members on the same plan, configurable confirmation before alerts, status pages that group and explain outages, and an MCP server any member can connect. ### Side by side | Upcertain | UptimeRobot Entry option | Basic: 10 monitors, 60 s, 1 status page | Free: 50 monitors, 5-minute interval 30-second checks | Team and Business | Team ($35 a month billed annually, $41 monthly), 100 monitors Fastest check | 30 s | 15 s on Scale Members who can log in | Unlimited on Team and Business, with roles | 3 on Team, 5 on Scale; more at $15 to $19 a month each People who only get alerts | Notify-only contacts | Notify-only seats Check locations | One region (Seoul) | Location-specific monitoring from 4 regions on paid plans Monitor types | HTTP, keyword, ping, port, SSL, heartbeat | Adds UDP, DNS, domain expiry, API field checks SMS and voice calls | No | Credits included on paid plans, more for sale Status pages | 1 on Basic, unlimited on Team and Business; password, custom domain | 1 to unlimited by plan; password, own domain, white label Prices | Early access, no billing yet | From $9 a month (Solo, billed annually) UptimeRobot's figures come from its pricing page, read on 25 October 2026. Check it for current prices. ### Where UptimeRobot does more It has a free plan with 50 monitors, which Upcertain does not. Paid plans add checks from several regions, SMS and voice-call alerts, a mobile app, UDP and DNS monitoring, domain-expiry warnings and 15-second intervals on its larger plans. If any of those is a requirement, UptimeRobot covers it and Upcertain does not. ### Where Upcertain is different - Seats. Team and Business include unlimited members with roles (owner, admin, editor, viewer), rather than a set number of login seats. - Confirmation you control. Each monitor sets 0 to 5 re-checks and the time between them, so deploy-time failures can be ignored without slowing real alerts. See confirmation checks. - Status pages that explain outages. Incidents that start together are grouped with each service's own downtime, and brief outages fold into one line a day. See status pages. - MCP for every member. Claude, Cursor and other clients connect with each person's own sign-in, read-only by default. See the MCP server. - Alert channels on every plan. Slack, Teams, Discord, Google Chat and signed webhooks are available on Basic too. ### Moving from UptimeRobot 1. List your UptimeRobot monitors: URLs or hosts, intervals and expected status codes. 2. Import them with a CSV file or a list of URLs, up to 200 rows at a time (CSV import). 3. Add alert channels and send a test to each. 4. Rebuild the status page and move your subdomain's CNAME to pages.upcertain.com (custom domains). 5. Run both for a week, then switch the old monitors off. #### Does Upcertain have a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. #### Can I keep notify-only contacts? Yes. Add them as notify-only contacts under Team: they receive email alerts and have no login. ## Upcertain and StatusCake compared Source: https://upcertain.com/compare/statuscake StatusCake offers uptime, page speed, domain, SSL and server monitoring with a free plan and two paid tiers. Upcertain covers a narrower set of checks with a different focus. ### The short version - Pick StatusCake if you want page speed tests, domain and blacklist monitoring, server resource monitoring, checks from chosen locations, SMS alerts or a free plan. - Pick Upcertain if you want 30-second checks with unlimited team members, tunable confirmation before alerts, heartbeat monitoring for scheduled jobs, status pages on your domain and an MCP server. ### Side by side | Upcertain | StatusCake Entry option | Basic: 10 monitors, 60 s | Free: 10 uptime monitors, 5-minute interval Middle plan | Team: 100 monitors, 30 s | Superior: 100 monitors, 1-minute interval, $20.41 a month annually ($24.49 monthly) Larger plan | Business: custom limits | Business: 300 monitors, 30 s, $66.66 a month annually ($79.99 monthly) Team members | Unlimited on Team and Business | Team member accounts on paid plans (1 or 9 by plan) Other checks | Keyword, ping, port, SSL, heartbeat | Page speed, domain, SSL, server monitoring Check locations | One region (Seoul) | Custom test locations, listed in the plan table SMS | No | 75 or 400 free SMS credits a month on paid plans Heartbeat (cron) monitoring | Yes | Not listed on the pricing page StatusCake's figures come from its pricing page, read on 25 October 2026. ### Where StatusCake does more StatusCake runs page speed tests, watches domain expiry, DNS records and blacklists, and monitors servers. It lets paid plans choose where tests run from and includes SMS credits. Upcertain does none of these. ### Where Upcertain is different - 30-second checks without a seat cap on Team, with roles for each member. - [Heartbeat monitors](/features/heartbeat-monitoring) for cron jobs, backups and workers. - Confirmation checks per monitor, 0 to 5 re-checks 15 to 120 seconds apart. - Status pages that group simultaneous incidents, show each service's downtime and fold brief outages. - An MCP server and REST API for AI agents and scripts. ### Questions to ask before you switch - Do you rely on page speed, domain or server monitoring? Upcertain does not run those. - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys fail for? That decides your confirmation settings. ### Moving from StatusCake 1. List your StatusCake monitors: URLs or hosts, intervals and expected status codes. 2. Import them with a CSV file or a list of URLs, up to 200 rows at a time (CSV import). 3. Add alert channels and send a test to each. 4. Rebuild the status page and move your subdomain's CNAME to pages.upcertain.com (custom domains). 5. Run both for a week, then switch the old monitors off. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. #### Can Upcertain test page speed? No. Each check records its response time, but Upcertain does not run page speed or browser tests. ## Upcertain and Hyperping compared Source: https://upcertain.com/compare/hyperping Hyperping combines uptime monitoring, status pages, on-call and logs, with a free plan and seat-based paid tiers. Upcertain covers monitoring, incidents and status pages for teams that want those without the rest. ### The short version - Pick Hyperping if you want on-call with escalation and phone calls, browser checks, server agents, logs, SMS subscribers or multilingual status pages. - Pick Upcertain if you want unlimited members on the Team plan, tunable confirmation, status pages that group and fold outages, and an MCP server every member can connect to. ### Side by side | Upcertain | Hyperping Entry option | Basic: 10 monitors, 60 s, 1 status page | Free: 20 monitors, 5-minute checks, 1 basic status page Paid plans | Team: 100 monitors, 30 s; Business: custom | Essentials $24, Pro $74, Business $249 a month, billed yearly Seats | Unlimited on Team and Business | 3, 10 or 20 included; extra users $7 to $12 a month Status pages | Unlimited on Team and Business, custom domain, password | 1, 3 or 10 by plan; custom domain from Essentials On-call and phone calls | No | From Essentials Browser checks | No | 3, 10 or 25 by plan Logs | No | 5 to 50 GB a month by plan AI access | MCP server and REST API | Ask Hyperping AI (alpha) on paid plans Hyperping's figures come from its pricing page, read on 25 October 2026. ### Where Hyperping does more Hyperping adds on-call schedules with escalation and phone-call alerts, browser checks, server monitoring agents, log storage, SMS subscribers, multilingual status pages and white labelling on its Business plan. For a team that wants one tool for all of that, Hyperping covers more. ### Where Upcertain is different - No per-seat pricing on Team: invite everyone who needs access, with roles. - Confirmation per monitor, tuned to how long your deploys fail. See deploy false alarms. - Status pages that explain outages: grouped incidents, per-service downtime, folded brief outages. - MCP for each member, with their own sign-in, read-only by default. ### Questions to ask before you switch - Which checks do you rely on today that Upcertain does not run, such as browser checks or checks from several regions? - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys fail for? That decides your confirmation settings. - Which status page domain and subscribers will move, and how will you tell subscribers? ### Moving from Hyperping 1. List your Hyperping monitors: URLs or hosts, intervals and expected status codes. 2. Import them with a CSV file or a list of URLs, up to 200 rows at a time (CSV import). 3. Add alert channels and send a test to each. 4. Rebuild the status page and move your subdomain's CNAME to pages.upcertain.com (custom domains). 5. Run both for a week, then switch the old monitors off. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Instatus compared Source: https://upcertain.com/compare/instatus Instatus is built around the status page, with monitoring included. Upcertain is built around monitoring, with status pages included. Which suits you depends on where you start. ### The short version - Pick Instatus if the status page is the main thing: large subscriber lists, SMS and call alerts on higher plans, on-call members and a free plan. - Pick Upcertain if monitoring comes first: six check types including heartbeats, confirmation before alerts, 30-second checks with unlimited members, and status pages that explain each outage. ### Side by side | Upcertain | Instatus Entry option | Basic: 10 monitors, 60 s | Starter: 15 monitors, 2-minute checks, 200 subscribers, no custom domain Middle plan | Team: 100 monitors, 30 s, custom domains | Pro: 50 monitors, 30-second checks, 1+ custom domain, 5,000 subscribers Larger plan | Business: custom limits | Business: 1,000 monitors, 25,000 subscribers, SAML SSO Team members | Unlimited on Team and Business | 5 on Starter, 50 on Pro Alerts | Email, Slack, Teams, Discord, Google Chat, webhooks | Email; SMS on Pro; SMS and calls on Business Monitor types | HTTP, keyword, ping, port, SSL, heartbeat | Not detailed on the pricing page Instatus's figures come from the latest archived copy of its pricing page, captured on 16 October 2026, because the live page did not load for us on 25 October 2026. ### Where Instatus does more Instatus offers larger subscriber allowances, SMS and call alerts on its paid plans, on-call members and SAML SSO on Business, and a free Starter plan. ### Where Upcertain is different - Monitoring depth: keyword, ping, port, SSL and heartbeat checks next to HTTP. - Confirmation checks per monitor, so short failures do not reach the page or the pager. - Outages explained: grouped incidents with each service's downtime, and brief outages folded per day. - Unlimited members on Team, and an MCP server for AI agents. ### Questions to ask before you switch - Which checks do you rely on today that Upcertain does not run, such as browser checks or checks from several regions? - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys fail for? That decides your confirmation settings. - Which status page domain and subscribers will move, and how will you tell subscribers? ### Moving from Instatus 1. List your Instatus monitors: URLs or hosts, intervals and expected status codes. 2. Import them with a CSV file or a list of URLs, up to 200 rows at a time (CSV import). 3. Add alert channels and send a test to each. 4. Rebuild the status page and move your subdomain's CNAME to pages.upcertain.com (custom domains). 5. Run both for a week, then switch the old monitors off. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Atlassian Statuspage compared Source: https://upcertain.com/compare/statuspage Atlassian Statuspage is widely used for status communication. Its plans are built around subscribers, components and team members; Upcertain's status pages are built from its own uptime monitors. ### The short version - Pick Statuspage if you need large subscriber lists, audience-specific pages per customer group, component subscriptions, deep customisation with CSS and JavaScript, or Atlassian's ecosystem. - Pick Upcertain if you want the status page and the monitoring behind it in one place, with the page updating from real checks and no per-subscriber tiers. ### Side by side | Upcertain | Statuspage (public pages) Free or entry option | Basic: 1 status page, 10 monitors | Free: 100 subscribers, 25 components, 2 team members Custom domain | Team and Business | Hobby ($29 a month) and above Plans | Early access, no billing yet | Hobby $29, Startup $99, Business $399, Enterprise $1,499 a month Subscribers | Email subscribers, no tier limits | 250 to 25,000 by plan Team members | Unlimited on Team and Business | 5 to 50 by plan Uptime checks | Built in: HTTP, keyword, ping, port, SSL, heartbeat | Not listed on the pricing page Private pages | Password-protected or members-only, on every plan | Separate private-page plans, from $79 a month Statuspage's figures come from the latest archived copy of its pricing page, captured on 17 October 2026, because the live page renders its prices in a way our tools could not read on 25 October 2026. ### Where Statuspage does more Statuspage offers audience-specific pages for different customer groups, component subscriptions, metrics on the page, SMS and webhook notifications to subscribers on higher plans, custom CSS, HTML and JavaScript, and team-member SSO through Atlassian Guard. ### Where Upcertain is different - The page updates itself from Upcertain's monitors, so it is current during the outage, while you are busy fixing it. - Outages explained: incidents that start together are grouped with each service's downtime, and brief outages fold into one line a day. - Password-protected and private pages on the same plan as public ones. - One tool for monitoring, alerts and the page, with an MCP server and REST API. ### Moving from Statuspage 1. Create monitors for each component you show on Statuspage. 2. Build the Upcertain status page with sections matching your component groups. 3. Point your status subdomain's CNAME at pages.upcertain.com (custom domains). 4. Tell subscribers about the move in a final Statuspage update and invite them to subscribe on the new page. #### Can I import my Statuspage subscribers? Not automatically. Subscribers confirm their own address on the new page, which also keeps the list clean. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Oh Dear compared Source: https://upcertain.com/compare/oh-dear Oh Dear monitors websites broadly, from uptime and certificates to broken links and DNS, and prices by how many sites you watch. Upcertain prices by plan and focuses on uptime, incidents and status pages. ### The short version - Pick Oh Dear if you want broken-link crawling, DNS monitoring, performance checks and verification from a second location, all in one per-site price. - Pick Upcertain if you monitor many endpoints per site (APIs, health checks, ports, jobs) and want 100 monitors on one plan, tunable confirmation and an MCP server. ### Side by side | Upcertain | Oh Dear Pricing unit | Plans by number of monitors | Plans by number of sites and servers Entry option | Basic: 10 monitors, 60 s | Solo: 2 sites, €15 a month as shown on the pricing page (billing period not stated); 10-day trial Larger plans | Team: 100 monitors; Business: custom | Up to 200 sites for €399 a month, then custom Features by plan | Custom domains, MCP and unlimited members from Team | Every feature on every plan Confirming a failure | 0 to 5 re-checks over time | Verified from a second location Other checks | Keyword, ping, port, SSL, heartbeat | Adds broken links, DNS, performance Oh Dear's figures come from its pricing page, read on 25 October 2026. ### Where Oh Dear does more Oh Dear checks more about each website: broken links, DNS and performance, alongside uptime, certificates, cron jobs and status pages. It verifies each alert from a second location, and includes single sign-on, two-factor and unlimited users on every plan. ### Where Upcertain is different - Monitors, not sites. A site with an API, a health endpoint, a mail server and three jobs is one site at Oh Dear and several monitors at Upcertain. Which is cheaper depends on how you monitor. - Confirmation over time you tune per monitor, for services whose deploys fail briefly. See confirmation checks. - Status pages that group simultaneous incidents and fold brief outages. - MCP and REST for agents and scripts. ### Questions to ask before you switch - Which checks do you rely on today that Upcertain does not run, such as browser checks or checks from several regions? - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys fail for? That decides your confirmation settings. - Which status page domain and subscribers will move, and how will you tell subscribers? ### Moving from Oh Dear 1. List your Oh Dear monitors: URLs or hosts, intervals and expected status codes. 2. Import them with a CSV file or a list of URLs, up to 200 rows at a time (CSV import). 3. Add alert channels and send a test to each. 4. Rebuild the status page and move your subdomain's CNAME to pages.upcertain.com (custom domains). 5. Run both for a week, then switch the old monitors off. #### Is there a free trial? No trial is needed: Upcertain is in early access, billing is not enabled, and accounts start on the Basic plan. ## Upcertain and Cronitor compared Source: https://upcertain.com/compare/cronitor Cronitor started with cron job monitoring and added uptime checks, status pages and browser checks. Upcertain started with uptime monitoring and includes heartbeats. The overlap is large; the pricing models are not. ### The short version - Pick Cronitor if you want deep cron telemetry, SMS and on-call integrations, synthetic browser checks or real user monitoring, and like paying per monitor. - Pick Upcertain if you want a plan with a set monitor count and unlimited members, status pages with custom domains and password protection included, and an MCP server. ### Side by side | Upcertain | Cronitor Pricing model | Plans by number of monitors | $2 a month per monitor plus $5 per user (Business) Entry option | Basic: 10 monitors, 60 s | Hacker: 5 monitors, 5-minute checks, 1 user Fastest check | 30 s on Team and Business | 30 s on Business Users | Unlimited on Team and Business | Paid per user on Business Private status page | Included (password or members only) | $50 a month per page Branded status page | Team and Business hide the footer link | $25 a month per page SMS and on-call integrations | No | Business Cronitor's figures come from its pricing page, read on 25 October 2026. ### Where Cronitor does more Cronitor records each cron run in detail, sends SMS, integrates with PagerDuty, Datadog On-Call, OpsGenie and Splunk On-Call, runs synthetic browser checks and collects real user monitoring events. It also offers SAML SSO and SCIM provisioning. ### Where Upcertain is different - Heartbeats and uptime in one place. Upcertain watches cron jobs with heartbeat monitors and also checks websites, APIs, ports and certificates, with the same alert channels and incidents for both. - Status pages that show jobs and websites side by side, on your own domain on Team and Business. - Periods from 30 seconds to 30 days with a grace period of up to a day. - MCP and REST so agents and scripts can read missed heartbeats like any other incident. ### Questions to ask before you switch - Do you rely on per-run cron telemetry or on-call integrations? Upcertain records whether a heartbeat arrived, not the job's output. - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from Cronitor 1. List what you monitor in Cronitor: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Healthchecks.io compared Source: https://upcertain.com/compare/healthchecks-io Healthchecks.io does one thing, cron job monitoring, and does it simply. Upcertain covers the same heartbeat pattern alongside website, API, port and certificate checks. ### The short version - Pick Healthchecks.io if you only need cron job monitoring, want a free tier for 20 jobs, or want SMS, WhatsApp and phone-call credits. - Pick Upcertain if you want jobs and websites monitored together, with one set of alerts, incidents and a status page. ### Side by side | Upcertain | Healthchecks.io Focus | Uptime checks plus heartbeats | Cron job monitoring Entry option | Basic: 10 monitors of any type | Hobbyist $0: 20 jobs Paid plans | Early access, no billing | Supporter $5, Business $20 (100 jobs), Business Plus $80 (1,000 jobs) a month Phone and SMS | No | Credits on Business and Business Plus Website, API and port checks | Yes | Not on its pricing page Open source | No | Business plan free for open-source projects Healthchecks.io's figures come from its pricing page, read on 25 October 2026. ### Where Healthchecks.io does more It keeps a log of each job's pings, offers SMS, WhatsApp and phone-call alerts on its Business plans, gives open-source projects its Business plan for free and charges little. If cron jobs are all you monitor, it is hard to beat on focus. ### Where Upcertain is different - Heartbeats and uptime in one place. Upcertain watches cron jobs with heartbeat monitors and also checks websites, APIs, ports and certificates, with the same alert channels and incidents for both. - Status pages that show jobs and websites side by side, on your own domain on Team and Business. - Periods from 30 seconds to 30 days with a grace period of up to a day. - MCP and REST so agents and scripts can read missed heartbeats like any other incident. ### Questions to ask before you switch - Do you need anything besides cron monitoring? If not, a focused tool may be enough. - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from Healthchecks.io 1. List what you monitor in Healthchecks.io: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Dead Man's Snitch compared Source: https://upcertain.com/compare/dead-mans-snitch Dead Man's Snitch is a long-running cron monitor with simple plans and unlimited team members. Upcertain offers the same dead man's switch pattern next to uptime monitoring. ### The short version - Pick Dead Man's Snitch if you only watch scheduled jobs and want smart alerts and error notices on its larger plan. - Pick Upcertain if you also need websites, APIs, ports and certificates checked, with status pages and an MCP server. ### Side by side | Upcertain | Dead Man's Snitch Focus | Uptime checks plus heartbeats | Cron job monitoring Entry option | Basic: 10 monitors, 60 s (early access, no billing) | One snitch Plans | Basic, Team, Business | Little Birdy $5 (3 snitches), Private Eye $19 (100), Surveillance Van $49 (300) a month Team members | Unlimited on Team and Business | Unlimited on every plan Status pages | Yes, custom domain on Team and Business | Not on its plans page Dead Man's Snitch's figures come from its plans page, read on 25 October 2026. ### Where Dead Man's Snitch does more Its larger plan adds smart alerts and error notices, and every plan has an API and the Field Agent for reporting in. It has been dedicated to cron monitoring for years. ### Where Upcertain is different - Heartbeats and uptime in one place. Upcertain watches cron jobs with heartbeat monitors and also checks websites, APIs, ports and certificates, with the same alert channels and incidents for both. - Status pages that show jobs and websites side by side, on your own domain on Team and Business. - Periods from 30 seconds to 30 days with a grace period of up to a day. - MCP and REST so agents and scripts can read missed heartbeats like any other incident. ### How the pattern works in Upcertain A heartbeat monitor expects a call to its unique URL within each period plus a grace time. The dead man's switch guide explains how to choose both. ### Moving from Dead Man's Snitch 1. List what you monitor in Dead Man's Snitch: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Does Upcertain have an equivalent of Field Agent? No separate agent is needed: any job can report in by calling its heartbeat URL with curl, wget or an HTTP client. #### Can a heartbeat fail on an error rather than a missed run? Report in only when the job succeeds, so an error stops the heartbeat. A job that fails early then shows up as a missed heartbeat at the deadline. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Pingdom compared Source: https://upcertain.com/compare/pingdom Pingdom is one of the longest-running website monitors, now part of SolarWinds, with uptime, transaction, page speed and real user monitoring. Upcertain focuses on uptime, incidents and status pages. ### The short version - Pick Pingdom if you need transaction checks that click through your site, page speed and real user monitoring, SMS alerts, or the SolarWinds platform. - Pick Upcertain if you want straightforward plans with alert channels for chat tools, heartbeat and port checks, tunable confirmation and an MCP server. ### Side by side | Upcertain | Pingdom Plans | Basic, Team, Business | Tiers by number of uptime and advanced checks, from 10 uptime checks, 1 advanced check and 50 SMS Prices | Early access, no billing | Set with a calculator on its pricing page Transaction and page speed checks | No | Yes Real user monitoring | No | Yes, priced separately SMS | No | Included per tier Users | Unlimited on Team and Business | Unlimited Heartbeat (cron) monitoring | Yes | Not on its pricing page Pingdom's details come from its pricing page, read on 25 October 2026. ### Where Pingdom does more Pingdom runs scripted transactions such as a sign-in or checkout, measures page speed, collects real user monitoring data and sends SMS alerts. Larger teams also get SolarWinds' infrastructure and application monitoring next to it. ### Where Upcertain is different - Alerts in chat tools on every plan: Slack, Teams, Discord, Google Chat and signed webhooks. - Heartbeat and port monitors for jobs and services without a web page. - Confirmation checks per monitor, tuned to your deploys. - Status pages that group incidents and fold brief outages, with custom domains on Team and Business. - MCP for agents and a REST API on every plan. ### Questions to ask before you switch - Do you rely on transaction or page speed checks? Upcertain does not run them. - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from Pingdom 1. List what you monitor in Pingdom: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Can Upcertain check that a checkout works? Not by clicking through it. A keyword monitor on the checkout page or a health endpoint that exercises the payment path catches many checkout failures. #### Does Upcertain measure page speed? Each check records its response time, but Upcertain does not load pages in a browser or score them. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Uptime.com compared Source: https://upcertain.com/compare/uptime-com Uptime.com offers a broad set of check types, from DNS and SMTP to transactions and real user monitoring, run from a global probe network. Upcertain covers a smaller set from one region. ### The short version - Pick Uptime.com if you need DNS, SSH, NTP, UDP or mail-protocol checks, transactions, real user monitoring, private locations or checks from many regions. - Pick Upcertain if HTTP, keyword, ping, port, SSL and heartbeat checks cover you, and you want 30-second checks, chat alerts and status pages with simple plans. ### Side by side | Upcertain | Uptime.com Check types | HTTP, keyword, ping, port, SSL, heartbeat | Adds DNS, SSH, NTP, UDP, SMTP, IMAP, POP, FTP, API, transactions, page speed, RUM Check frequency | Down to 30 s | 1 minute Locations | One region (Seoul) | Global probe network, private locations Alerts | Email, Slack, Teams, Discord, Google Chat, webhooks | Email, SMS and 20+ integrations Users | Unlimited on Team and Business | Unlimited Prices | Early access, no billing | Set with a calculator on its pricing page Uptime.com's details come from its pricing page, read on 25 October 2026. ### Where Uptime.com does more More check types, checks from many locations including your own private ones, transactions and real user monitoring, SMS alerts and more integrations. For an operations team that needs breadth, it covers more ground. ### Where Upcertain is different - 30-second checks on Team and Business. - Confirmation over time you tune per monitor, rather than more locations. - Status pages that explain outages with per-service downtime and folded brief outages. - MCP for agents, and plans without a price calculator. ### Questions to ask before you switch - Which of your checks need more than HTTP, keyword, ping, port, SSL or heartbeat? - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from Uptime.com 1. List what you monitor in Uptime.com: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Why would checks from one region be enough? Many outages are on the service itself: a crash, a full disk, a bad deploy. One region sees those as well as many do. Regional network problems are the case it can miss. #### Does Upcertain support private locations? No. For services on a private network, run a small job inside the network that checks them and calls a heartbeat URL. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Site24x7 compared Source: https://upcertain.com/compare/site24x7 Site24x7, from Zoho, monitors websites, servers, applications, networks and cloud services in one suite. Upcertain is a focused uptime, incident and status page service. ### The short version - Pick Site24x7 if you want websites, servers, applications and networks in one suite, a free plan, or Zoho's ecosystem. - Pick Upcertain if you want uptime monitoring that a small team can set up in an afternoon, with 30-second checks, chat alerts, status pages and MCP. ### Side by side | Upcertain | Site24x7 Scope | Uptime, incidents, status pages | Full monitoring suite Entry option | Basic: 10 monitors, 60 s (early access, no billing) | A free plan without an end date; 30-day trial of paid plans Website check interval | Down to 30 s | 1 minute on most website plans; 30 s on larger plans Prices | Early access, no billing | Shown by script on its pricing page MCP server | Yes | Not on its pricing page Site24x7's details come from its pricing page, read on 25 October 2026. ### What the table leaves out Comparing a suite with a focused tool on price alone is misleading. Site24x7's plans bundle server and application monitoring that Upcertain does not offer, while Upcertain's plans count only uptime monitors. Compare the monitors you actually need, at the interval you need them. ### Where Site24x7 does more It monitors far more than websites: servers, applications, networks and cloud resources, with dashboards and reports across them. A free plan lets you start without paying. ### Where Upcertain is different - One job done simply: uptime checks, confirmed incidents, alerts and status pages. - 30-second checks on Team and Business. - Heartbeats for scheduled jobs next to website checks. - MCP so Claude or Cursor can answer "what is down?". ### Questions to ask before you switch - Do you monitor servers, applications or networks in the same tool today? - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from Site24x7 1. List what you monitor in Site24x7: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Can Upcertain monitor server resources? No. It checks whether services answer from outside: HTTP, ping, ports, certificates and heartbeats. Use a server monitoring tool for CPU, memory and disk. #### Does Upcertain have reports? Owners and admins can have a weekly or monthly uptime report emailed, and the REST API returns uptime for 24 hours, 7, 30 and 90 days. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and OpenStatus compared Source: https://upcertain.com/compare/openstatus OpenStatus combines status pages with multi-region uptime monitoring and a free plan. Upcertain combines status pages with single-region monitoring, more check types and an MCP server. ### The short version - Pick OpenStatus if you need checks from several regions, or a free plan covering a single monitor and status page. - Pick Upcertain if you want keyword, port, SSL and heartbeat checks, 30-second intervals, unlimited members and status pages without per-page add-ons. ### Side by side | Upcertain | OpenStatus Entry option | Basic: 10 monitors, 60 s (early access, no billing) | Free: 1 monitor, 1 status page, 10-minute checks Paid plans | Team, Business | Starter $30, Pro $100, Scale $500 a month Monitors | 10, 100 or 500 (adjustable on Business) | 20 or 50, plus packs of 10 for $15 a month Status pages | Unlimited on Team and Business | 1, 5 or 10, extra pages $20 a month each Regions | One (Seoul) | Multi-region monitoring OpenStatus's figures come from its pricing page, read on 25 October 2026. ### What the table leaves out Multi-region checks and confirmation over time solve different problems. Several regions tell you whether a failure is local to one network; re-checks over time tell you whether a failure lasts long enough to matter. Upcertain does the second. Which matters more depends on where your users are. ### Where OpenStatus does more It checks from several regions, which separates regional network trouble from real outages, and has a free plan covering one monitor and one status page. ### Where Upcertain is different - More check types: keyword, ping, port, SSL and heartbeat next to HTTP. - 30-second checks and unlimited status pages on Team. - Status pages with grouped incidents, per-service downtime and folded brief outages. - MCP and REST for agents and scripts. ### Questions to ask before you switch - Do you need checks from several regions? Upcertain checks from one. - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from OpenStatus 1. List what you monitor in OpenStatus: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Can I put the status page on my own domain? Yes, on Team and Business, with the HTTPS certificate issued automatically. See custom domains. #### Are there per-page add-on fees? No. Team and Business include unlimited status pages, password protection and custom domains. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and Pulsetic compared Source: https://upcertain.com/compare/pulsetic Pulsetic covers website, SSL, port, keyword and cron monitoring with status pages, checked from several regions. Upcertain covers a similar set from one region, with an MCP server. ### The short version - Pick Pulsetic if you want region checks, SMS and call alerts, monitor screenshots, status page translation or a free plan. - Pick Upcertain if you want tunable confirmation, unlimited members on Team, status pages that explain outages, and MCP. ### Side by side | Upcertain | Pulsetic Entry option | Basic: 10 monitors, 60 s (early access, no billing) | Free: 10 monitors, 5-minute checks, 3 regions Paid plans | Team, Business | Solo $9, Team $19 (discounted from $39 when read), Organization $49 (from $69) a month Fastest check | 30 s (Team, Business) | 60 s on Solo, 30 s on Team and Organization Regions | One (Seoul) | 3 to 15 by plan SMS and calls | No | None on Free; 30+ to 200+ included on paid plans Pulsetic's figures come from its pricing page, read on 25 October 2026. ### What the table leaves out The plans differ in what they count. Pulsetic's limits count monitors, heartbeats and domains together and add regions as plans grow; Upcertain's count active monitors of any type, with members unlimited from Team upwards. Map your own list of checks before comparing prices. ### Where Pulsetic does more Region checks, SMS and call alerts, screenshots of failing monitors, real user monitoring and status page translation. ### Where Upcertain is different - Confirmation checks you set per monitor, tuned to your deploys. - Unlimited members with roles on Team and Business. - Status pages with grouped incidents and per-service downtime. - MCP for Claude, Cursor and other agents. ### Questions to ask before you switch - Do you need SMS or call alerts, or region checks? - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from Pulsetic 1. List what you monitor in Pulsetic: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Can Upcertain take screenshots of failing pages? No. Incidents record the failed request and the start of the response body instead. #### Does Upcertain translate status pages? No. Status pages are in English, with the names and announcements you write. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upcertain and HetrixTools compared Source: https://upcertain.com/compare/hetrixtools HetrixTools monitors websites and servers from 12 locations and watches IP and domain blacklists, with a free tier. Upcertain focuses on uptime, heartbeats and status pages. ### The short version - Pick HetrixTools if you need blacklist monitoring for mail servers, checks from many locations, SMS or phone alerts, or a free tier of 15 monitors. - Pick Upcertain if you want 30-second checks, heartbeats for jobs, chat alerts, status pages with grouped incidents and MCP. ### Side by side | Upcertain | HetrixTools Entry option | Basic: 10 monitors, 60 s (early access, no billing) | 15 uptime monitors, 1-minute checks Paid plans | Team, Business | From $9.95 a month Locations | One (Seoul) | 12 locations Alerts | Email and chat tools, webhooks | 20+ channels including SMS and phone calls Blacklist monitoring | No | Yes Heartbeat monitoring | Yes | Not on its uptime pricing page HetrixTools' figures come from its uptime monitor pricing page, read on 25 October 2026. ### What the table leaves out HetrixTools' free tier and location count are generous for a few servers. Upcertain's advantage is in what happens after a failure: confirmation before alerting, incidents your team acknowledges, and a status page that explains the outage to customers. ### Where HetrixTools does more Blacklist monitoring is useful for anyone running mail servers, and checks from 12 locations with SMS and phone alerts cover more than Upcertain does. ### Where Upcertain is different - 30-second checks on Team and Business. - Heartbeat monitors for cron jobs and workers. - Status pages that group incidents and fold brief outages. - MCP and REST for agents and scripts. ### Questions to ask before you switch - Do you rely on blacklist monitoring? Keep it where it is if so. - Who needs a login, and who only needs alerts? Notify-only contacts cover the second group. - How long do your deploys or jobs normally take? That decides confirmation checks and heartbeat grace. ### Moving from HetrixTools 1. List what you monitor in HetrixTools: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Can Upcertain monitor a mail server? It can check that the server accepts connections on its port, such as 587 or 25, with a port monitor. It does not check blacklists or deliverability. #### Do checks run every minute? Every 60 seconds on Basic and as often as every 30 seconds on Team and Business. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Upptime or a hosted monitor: how to choose Source: https://upcertain.com/compare/upptime Upptime is a clever open-source project: it turns GitHub Actions into an uptime monitor, GitHub Issues into incident reports and GitHub Pages into a status site. It costs nothing if you already use GitHub. ### How Upptime works According to its README, a GitHub Actions workflow visits your sites every 5 minutes, records response times in git, opens an issue when an endpoint is down and closes it when it recovers, and publishes a status site with GitHub Pages. It is MIT-licensed and configured in a single file. ### Side by side | Upcertain | Upptime Runs on | Upcertain's servers | Your GitHub repository's Actions Check interval | 30 s to 24 h | Every 5 minutes Incidents | Confirmed incidents with acknowledgement | GitHub Issues opened and closed automatically Alerts | Email, Slack, Teams, Discord, Google Chat, webhooks | Slack notifications Status page | Hosted, custom domain, password or private | GitHub Pages site Monitor types | HTTP, keyword, ping, port, SSL, heartbeat | Endpoint checks Upptime's details come from its README on GitHub, read on 25 October 2026. ### What the table leaves out Upptime's interval is limited by how GitHub schedules workflows, and scheduled workflows can start late when GitHub is busy. For a status page that is fine; for alerting a team within a minute, a dedicated monitor is more predictable. ### When Upptime is enough - Open-source projects whose community already lives on GitHub. - Side projects where a 5-minute interval is fine. - Teams that want every check result in git. ### When a hosted monitor fits better - You need to know within a minute, not five. See check intervals. - You want confirmation before alerting, so a single failed request does not open an issue. - You need heartbeats, port or certificate checks. - Your status page needs a password, subscribers or a custom domain with HTTPS handled for you. - You do not want monitoring to depend on scheduled workflows in the same platform as your code. ### Moving from Upptime 1. List what you monitor in Upptime: URLs, hosts or jobs, with their intervals. 2. Import URLs and hosts with a CSV file, up to 200 rows at a time (CSV import); add heartbeat monitors one by one. 3. Add alert channels and send a test to each. 4. Point your status page subdomain at pages.upcertain.com if you had one (custom domains). 5. Run both side by side for a week before switching the old checks off. #### Does Upcertain store results in git? No. Results live in Upcertain, and the REST API returns monitors, uptime and incidents for your own records. #### Is a 5-minute interval a problem? It depends on how fast you need to know. A 5-minute interval misses most outages shorter than a few minutes and takes up to 5 minutes to notice one. #### Can I use both? Yes. Keep Upptime's public history for your community, and use Upcertain for fast, confirmed alerts to your team. ## Uptime monitoring for agencies Source: https://upcertain.com/for/agencies An agency looks after dozens of sites it did not always build, for clients who notice an outage before anyone else. The work is keeping those sites watched, the right people told, and clients informed. ### Organise by client - Groups: put each client's monitors in a group named after the client. The monitor list shows each group as its own section. - Tags for the cross-cutting views: wordpress, shop, retainer. - Import a client's sites in one go from a CSV with a group column; groups are created as needed. See CSV import. ### What to monitor for each client Check | Why Home page, HTTP | The first thing the client looks at Key page, keyword | Catches error pages that still return 200, such as a broken plugin SSL certificate | Every HTTPS monitor warns 30, 14 and 7 days before expiry Contact form or checkout endpoint | Where lost leads and orders happen Backups and scheduled jobs, heartbeat | Silent failures you are paid to prevent ### Tell the right people - Route each client's monitors to the channel of the team that looks after them: one Slack channel per client or per team. - Add client contacts as notify-only members: they get email alerts for the events you choose, and have no login. - Use confirmation checks so a client never gets an alert for a blip. - Turn on weekly or monthly reports to have each period's uptime and incidents emailed. ### A status page per client On Team and Business you can create unlimited status pages: one per client, showing only that client's monitors under the names they recognise. Put each on the client's own subdomain, such as status.client.com, and hide the Upcertain footer link (Team and Business). Pages can be public, or password-protected for clients who would rather not show their status publicly. See status pages and custom domains. ### When a client has its own account Some clients want their monitoring in an account they own. The client creates the account and invites your team members with the role they choose; each account's data stays separate at the database level, and you switch between the accounts you belong to. ### Size and plan Team includes 100 monitors at 30-second checks, unlimited status pages and members, and custom domains. Business sets custom limits for agencies with more. See pricing or talk to us. #### Can clients see each other's monitors? Not on their status pages: each page shows only the monitors you put on it. Members of an account see all of that account's monitors, so give clients notify-only access or their own account. #### Can I white-label the status pages? Team and Business can hide the "Powered by Upcertain" link and put each page on the client's domain with the client's logo. ## Uptime monitoring for SaaS teams Source: https://upcertain.com/for/saas For a SaaS product, an outage is lost trust as well as lost time. Monitoring has to cover more than the home page, reach the right engineer quickly and keep customers informed without the support inbox filling up. ### What to monitor Service | Monitor | Interval Marketing site | HTTP | 1 to 5 min App sign-in page | Keyword: text that appears only when it works | 30 s Public API | HTTP on a health endpoint that checks the database | 30 s Webhooks you send | Heartbeat from the delivery worker | per run Billing, reports, exports | Heartbeat from each scheduled job | per run Every certificate | Comes with HTTPS monitors | with the check ### Alert the owner, not everyone - Give each team its own channel: the API in #api-oncall, billing jobs in #billing. - Tune confirmation checks to your deploys, so a rolling restart does not page anyone. The deploy guide shows the numbers. - Turn on alert grouping so a database outage arrives as one message listing every affected service. - Send failures into your own tooling with signed webhooks. ### Tell customers before they ask A status page on status.yourproduct.com updates from the monitors on its own. Incidents that start together are shown as one with each service's downtime, brief blips fold into a daily line, and planned maintenance appears ahead of time. Customers can subscribe to the updates you publish. ### Give your tools and agents access The REST API lets your pipeline pause monitors during a migration or read incidents into a dashboard. The MCP server lets engineers ask Claude or Cursor what is down without leaving their editor. ### A first week 1. Day one: monitor the sign-in page, the API health endpoint and the marketing site, with alerts to one shared channel. 2. Add heartbeats to the scheduled jobs customers would notice first: billing, exports, emails. 3. Watch a few deploys in the check log and set confirmation checks just above how long they fail. 4. Split alerts by owner once you know which services page which team. 5. Publish the status page and link it from your app's help menu and error pages. ### Roles that match your team Owners and admins manage billing-sensitive settings and API keys; editors manage monitors and acknowledge incidents; viewers read; notify-only contacts get email alerts without a login. Team and Business include unlimited members. ### What Upcertain does not do It checks from one region (Seoul), and it has no browser transaction checks, phone or SMS alerts, or on-call schedules. Many SaaS teams pair it with an on-call tool through a webhook. #### How fast will we hear about an outage? With 30-second checks and one confirmation check after 15 seconds, typically 15 to 45 seconds after the outage starts: up to 30 s until the next check, then 15 s to confirm. Add up to 20 s when alert grouping is on, and any delay you set on a channel. ## Uptime monitoring for side projects Source: https://upcertain.com/for/side-projects A side project gets an hour here and there, not an on-call rotation. Monitoring should run without attention and only speak up when something is really broken. ### A setup that fits in ten monitors Monitor | What it catches Home page, HTTP, every minute | The site is down or erroring App or API page, keyword | The page loads but the app behind it is broken Heartbeat from your scheduled jobs | The cron job, queue worker or backup stopped Database or mail port, if public | A service went away The Basic plan includes 10 monitors checked as often as every 60 seconds, one status page and every alert channel. That covers most projects with room to spare. ### Alerts that respect your evenings - Send alerts to where you already are: Discord, Slack, Google Chat or email. - Keep the default confirmation check, so a single dropped request never interrupts dinner. - Leave repeat reminders off; one alert and one recovery message are enough. - Add a second channel only for the monitors that matter most, so a broken blog does not ping your phone. ### Hosting platforms and scheduled jobs Free and hobby tiers on hosting platforms often sleep or pause projects, and scheduled functions can stop without notice. A heartbeat from each job is the only way to hear about the second kind. The cron monitoring guide shows the one-line change. ### A status page your users can find Point users at upcertain.com/s/ when they ask whether it is down. Add the status badge to your README so they see the state before they open an issue. ### When it does alert 1. Open the incident from the alert. The cause is recorded: a status code, a timeout, a missing keyword or a missed heartbeat. 2. Acknowledge it if it will take a while, so the record shows you are on it. 3. Check the last deploy or the hosting platform's own status page first; most side-project outages start there. 4. When it recovers you get a second message with the total downtime, and the incident closes on its own. ### Ask your editor If you build with Claude Code or Cursor, the MCP server can tell you what is down while you code. MCP is part of the Team plan; on Basic, the REST API gives scripts the same data. #### Will monitoring wake a sleeping app on a hosting platform? A request every minute may keep some platforms from putting an app to sleep, and on others it will not. Check your platform's rules; the monitor's job is to tell you when the app does not answer. #### Is there a free plan? Upcertain is in early access: billing is not enabled, accounts start on the Basic plan and plans are assigned from the account. ## Uptime monitoring for WordPress sites, without a plugin Source: https://upcertain.com/for/wordpress A monitoring plugin runs inside WordPress, so it goes down with the site it is meant to watch. Checking from outside needs nothing installed and sees what your visitors see. ### What breaks on WordPress sites - A plugin or theme update causes a fatal error, and WordPress shows its "There has been a critical error on this website" page. - The database connection fails and every page shows an error. - The hosting account is suspended or out of resources. - The certificate does not renew. - Scheduled tasks stop running because WP-Cron only runs when someone visits. ### A monitoring setup Monitor | Settings | Catches Home page, HTTP | Expect 200, every 1 to 5 min | The site is down or erroring Home page, keyword | Must not contain critical error | Fatal error pages, including copies served from a cache Key page, keyword | Must contain a phrase only that page has | A broken theme or page builder SSL | Comes with HTTPS monitors | Certificate expiry and errors Heartbeat | From a real cron job, see below | Scheduled tasks that stopped ### Run WP-Cron from a real cron job WP-Cron fires on page visits, so a quiet site runs its scheduled tasks late or not at all. A common fix is to disable the visit trigger with define('DISABLE_WP_CRON', true); in wp-config.php and run it from the server's cron instead. Add a heartbeat so you hear if that stops: */5 * * * * cd /var/www/site && wp cron event run --due-now --quiet && curl -fsS -m 10 https://upcertain.com/api/heartbeat/ The example uses WP-CLI. Create a heartbeat monitor with a 5-minute period and a few minutes of grace. ### After updates Most WordPress outages follow an update. Keep a keyword monitor on the pages that use your most complex plugins, and look at the monitor right after updating. An agency looking after many sites can import them all at once; see uptime monitoring for agencies. ### Tell visitors For a shop or membership site, a status page on a subdomain tells customers you know about a problem, even while the site itself is down. #### Can I monitor many WordPress sites at once? Yes. Import them from a CSV file or a list of URLs, up to 200 at a time, and group them by client. #### What about multisite networks? Monitor the main site and one page from each important subsite; each URL is its own monitor. #### Will checks slow my site down? One request a minute is negligible for any WordPress host. Avoid monitoring a page that triggers heavy work on each load. #### Should I monitor wp-admin? Usually not. Monitor the public pages visitors use; the admin area redirects to the login page and changes with every update. ## Uptime monitoring for Shopify stores Source: https://upcertain.com/for/shopify Shopify keeps its platform running. What it does not watch is whether your theme renders products, your apps load, or the services you connected to the store still answer. ### What can break on a Shopify store - A theme edit or app removes the add-to-cart button or the product grid. - An app script fails and blocks parts of the page. - Your custom domain's DNS changes and the store stops resolving. - Your own backend (a fulfilment service, a webhook receiver, a custom app) goes down. - A platform incident, which Shopify reports on its own status page. ### A monitoring setup Monitor | Settings Storefront home, keyword | Must contain a phrase from your header or a featured product Best-selling product page, keyword | Must contain the add-to-cart button's text Collection page, keyword | Must contain a product name that is always listed Your webhook receiver or custom app | HTTP on its health endpoint Jobs that sync stock or orders | Heartbeat Keyword checks read the HTML Shopify serves. Text added later by JavaScript in the browser is not visible to them, so pick text that is in the page source. ### Integrations you own Many stores depend on services outside Shopify: a fulfilment or inventory system, a review widget's API, a custom app that receives order webhooks. Shopify cannot tell you when those fail. Give each one an HTTP monitor on its health endpoint, and a heartbeat for each scheduled sync, so a stock feed that silently stops is noticed before you oversell. Put the store and these services on one status page for your team, private if you prefer, so everyone sees the whole chain in one place. ### Checkout Checkout runs on Shopify's systems and is not something an outside monitor can complete without placing orders. Monitor the pages that lead to it, and your own services that orders depend on. ### Alerts Send store alerts where your team works, such as Slack or email, and give a manager or client notify-only access if they only need to know. Use confirmation checks so a single slow response does not alert anyone. ### During a sale Before a big sale, shorten the interval on the product and collection pages and make sure someone is watching the alert channel. After it, return to a calmer interval. #### Will monitoring count as traffic in Shopify analytics? Checks are plain HTTP requests without a browser, so most analytics that run in the browser do not count them. #### How often should a store be checked? Every minute is a good default; tighten it before and during sales. #### Does Shopify not monitor my store already? Shopify monitors its platform. It does not know whether your theme, apps and own services work the way you expect. ## Website monitoring for small businesses Source: https://upcertain.com/for/small-business When a small business website stops working, the first person to notice is often a customer who gives up. Monitoring tells you first, so you can call your web person before the phone rings. ### What to watch - The home page: is the site up at all? - The page that makes money: a booking form, a contact form, an online shop. A keyword check makes sure the form or shop actually appears. - The security certificate: an expired one shows visitors a warning page. Upcertain warns you weeks ahead. ### Who should hear Alerts can go to you by email and to whoever looks after your website, such as a freelancer or an agency. Someone who only needs to know can be a notify-only contact without a login. ### What to do when an alert arrives 1. Open the alert: it says what failed and since when. 2. Forward it to whoever manages your website or hosting, with the time it started. 3. Check your hosting provider's status page, in case the problem is theirs. 4. You get a second message when the site is back, with how long it was down. ### Do I need this if my host promises uptime? A hosting promise usually means a partial refund after an outage, not a warning while it happens. It also does not cover your site's own problems, such as a broken plugin or a booking form that stopped working. Monitoring watches the site itself. ### A simple monthly check-up - Look at the month's uptime and any incidents in the app or the monthly report email. - Check that the alert contacts are still the right people. - After any website change, make sure the keyword checks still match the pages. Ten minutes a month keeps monitoring useful. An alert that goes to someone who left the business is the same as no alert. ### Getting started Upcertain is in early access: billing is not enabled and accounts start on the Basic plan, which covers 10 monitors checked every minute and one status page. Guided setup turns your website's address into the right checks in one step. See how to monitor website uptime. #### What if I have more than one website? Add each one as its own monitor and group them, so alerts and the monthly report show which site had a problem. #### Do I need technical knowledge? No. You enter your website's address and choose who gets alerts. Someone technical helps when something does break. #### Will monitoring change my website? No. Checks visit your site from outside like a visitor; nothing is installed. #### Can my web designer see the alerts too? Yes. Add their email to the alert channel or make them a notify-only contact; on Team and Business you can also invite them with a login. ## How Upcertain decides a site is down Source: https://upcertain.com/blog/how-we-decide-a-site-is-down "Is it down?" sounds like a yes-or-no question. In practice a monitor has to decide from a handful of requests whether to wake someone up. Here is exactly how Upcertain makes that call. ### 1. A scheduled check runs Every monitor has an interval, from 30 seconds to 24 hours. When it is due, a worker in Seoul runs the check. That is an HTTP request, a keyword match on the response, a ping, a TCP connection or a certificate inspection. For heartbeat monitors it is a look at when the job last reported in. Each result is recorded with its response time. A failure also records a reason we can name: a status code outside what you expect, a timeout, a missing or unwanted keyword, a DNS failure or a refused connection. For certificates, the reason is that one is expired, issued for the wrong host or badly chained. ### 2. A failure is not an outage yet The internet drops packets. Containers restart. Load balancers move traffic. A single failed request says very little, so the first failure starts a short investigation instead of an incident. The monitor re-checks after its confirmation delay (15, 30, 60 or 120 seconds) as many times as you set, from 0 to 5. If any re-check passes, the episode ends quietly. The failures stay in the check log, but nobody is alerted and nothing appears on your status page. New monitors use one re-check after 15 seconds. Services that fail predictably during deploys can use more; we walk through an example in downtime alerts during deploys. ### 3. Confirmed: the incident opens When every re-check fails, Upcertain opens an incident. Its start time is the first failed check, not the moment it was confirmed, so the recorded downtime is honest about how long users were affected. ### 4. The right people hear once - Each monitor lists its alert channels. Each channel can wait a set delay before alerting (0 to 1440 minutes), so email to a wider group can wait while the on-call Slack channel hears at once. - If several monitors fail within a few minutes and alert grouping is on, they arrive as one alert listing them all. A shared database going down should be one message, not twenty. - Reminders repeat while the incident stays open, if you asked for them, every 5 to 1440 minutes. - Someone acknowledges the incident in Upcertain. Reminders stop on every channel and the incident records who took it. Failed deliveries are retried at 30 seconds, 1, 2 and 4 minutes. Email goes to each recipient separately, with a personal link to stop alerts and an Acknowledge button only for people whose role can acknowledge. ### 5. Recovery The first passing check resolves the incident. Every channel that received the alert gets the recovery, with the total downtime, in the same place. There is no confirmation on the way up: if the service fails again, a new episode starts. ### 6. What the status page shows Status pages read the same incidents. Incidents that start within 2 minutes of each other are shown as one event ("Web app, API and 8 more were unavailable"), with each service's own downtime, because services on different check cycles notice the same failure a few seconds apart. Short incidents can be folded into one line per day. The reasoning is in brief outages on status pages. ### What we do not do We check from one region. A tool that checks from several places can tell a regional network problem from a real outage and report regional availability; ours cannot. We chose confirmation over time instead, which handles the most common cause of false alarms we see: short failures on the service itself. ### Why this order Every rule above trades a little speed for a lot of trust. Teams that get false alarms soon stop reading alerts. With the defaults, a real outage on a 30-second monitor reaches Slack within about 45 seconds; a monitor tuned to ignore 90-second deploy failures reports real outages within about two minutes. We would rather you hear about a real outage a minute later than learn to ignore the channel. ## Brief outages on status pages: why we fold them and show each service's downtime Source: https://upcertain.com/blog/brief-outages-on-status-pages A status page has two readers: the customer asking "is it down right now?" and the one checking "how reliable are they?" A list of forty 50-second blips serves neither. Here is how we show outages instead. ### The problem with a raw incident list Run a status page for a few weeks and the incident list fills with entries like "API was unavailable for 48 seconds". Each is true. Together they bury the outage that mattered, a 25-minute failure on Tuesday, under a wall of noise, and they make a reliable service look fragile. Hiding short incidents is no better. Customers who saw an error and then find nothing on the status page stop trusting it. ### Grouping what happened together When a shared dependency fails, every service behind it goes down at about the same time. Monitors check on their own cycles, so they notice a few seconds apart: one at 09:14:03, another at 09:14:21. Listed separately, that is ten incidents. It was one event. Upcertain shows incidents that start within 2 minutes of each other as one: "Web app, API and 8 more were unavailable", with the cause, the time range in the page's time zone and the duration. Expanding it shows a plain description, when it started and was resolved, and each affected service. ### Each service's own downtime A grouped event runs from the first failure to the last recovery. With several services, that span can be longer than any one of them was down, because each was noticed and recovered on its own cycle, up to a check interval apart. So the page also says how long each service itself was down: "lasted 1 m 2 s; each service down 46 to 48 s". The REST API and MCP server report the same per-service durations. ### Folding brief outages The owner of each page chooses what counts as brief: 1, 2, 5, 10, 15 or 30 minutes, 5 by default. Ongoing incidents and anything longer get their own card. A day's brief ones fold into one expandable line: 6 brief outages · each under 5 minutes · 7 m 30 s in total Nothing is lost. The line expands to every incident, the total time is right there, and uptime still counts every minute. ### Hiding them, honestly Some teams prefer to leave brief outages off the page entirely. That is an option, with one rule we would not give up: the page says how many were not listed. Uptime figures still include them. A reader can always see that something was left out and how much. ### History by month The main page covers the last 7 days, grouped by day in the page's time zone. A history page shows 90 days of incidents, one month at a time, with the same grouping and folding. ### What we learned building it - Grouping needs a window. Two minutes catches services failing together on 30-second and 60-second cycles without merging unrelated incidents. - Durations confuse people when they disagree. Showing both the event span and each service's downtime made the timing easier to read. - "Brief" depends on the business. A 4-minute outage is brief for a documentation site and serious for a payment API, so the threshold is the page owner's choice. You can see it on our own status page, and set it up from your monitors in a few minutes: status pages. ## Ask Claude what's down: connecting your uptime monitors over MCP Source: https://upcertain.com/blog/ask-claude-whats-down During an incident, the first questions are always the same: what is down, since when, what else is affected, has this happened before? With Upcertain connected over MCP, you can ask Claude instead of clicking through dashboards. ### What MCP gives Claude The Model Context Protocol lets an AI client call tools on a server. Upcertain's MCP server at https://upcertain.com/api/mcp offers tools to list monitors, read a monitor's uptime over 24 hours, 7, 30 or 90 days, list and read incidents with their activity, and list status pages. With read-write access it can also create, pause and resume monitors and acknowledge incidents. ### Connect Claude Add https://upcertain.com/api/mcp as a custom connector in Claude, or as an HTTP server in Claude Code, and sign in when Upcertain opens in your browser. You choose the workspace and read-only or read-write access there. The steps for each client are in the docs for Claude, Claude Code and Cursor. MCP is included on the Team and Business plans. A useful habit is to start an incident conversation with the broad question and narrow from there. Claude calls the list tools first, then fetches the incident or monitor you ask about, so you see the same records your team sees in the app. ### Questions that work well #### During an incident - "What's down right now, and since when?" - "Did anything else fail in the ten minutes before checkout went down?" - "Has the payments API had incidents like this before? Show the last five with causes." #### For reports - "Make a table of 30-day uptime for every monitor, worst first, with the number of incidents." - "Summarise this week's incidents for a status update to customers." - "Which monitors have had the most incidents in the last 90 days?" #### For changes (read-write) - "Add HTTP monitors for these five URLs every minute, expecting 200." - "Pause the staging monitors; I'll ask you to resume them after the migration." - "Acknowledge the open incident on auth-service." ### Safeguards we built in - Read-only by default. Every new connection starts read-only. Read-write is offered only to people whose role can make changes. - One person, one connection. Each sign-in is its own connection, listed under Settings, API & MCP, Connected apps, and can be disconnected by its owner or by an account owner or admin. - Follows the membership. Leave the account or become notify-only and the connection ends; lose the right to make changes and it becomes read-only. - Same limits as the API. Tool calls share the REST API's limit of 60 requests a minute per key or connected app, and run with your own permissions, so Claude sees exactly what you can see. - Upcertain is its own authorisation server. Tokens issued to Claude work only for the MCP server, not for the rest of the platform. ### What it is not Claude reads what Upcertain knows: monitors, checks, incidents and status pages. It does not see your logs or servers, so "why did it fail?" gets the recorded cause (a 503, a timeout, a missing keyword) rather than a root-cause analysis. Combine it with the tools that hold your logs if you want both in one conversation. ### Prefer scripts? The same data is available from the REST API with an API key, which owners and admins create. Both are described on the MCP server page. ## Freshping shut down in 2026. What to look for in the next monitor Source: https://upcertain.com/blog/freshping-shutdown-what-next Freshworks retired Freshping, its website monitor, with free plan access ending on 6 March 2026. If your checks lived there, you have probably rebuilt them in a hurry. It is worth a second look at what you actually need. ### What happened Freshworks told users by email that Freshping was being retired, with 6 March 2026 as the last day of free plans and of renewals. Teams that relied on it needed somewhere else to go. The dates and sources are on our Freshping page. ### A checklist for the replacement #### How often it checks, and how it confirms A short interval only helps if failures are confirmed before anyone is alerted. Ask how a tool decides an outage is real: re-checks over time, checks from several locations, or nothing at all. Read more about check intervals and confirmation checks. #### What it can check HTTP status is the minimum. Keyword checks catch pages that return 200 with an error on them. Certificate expiry warnings prevent the most avoidable outage there is. Heartbeat monitors cover cron jobs and backups, which website checks cannot see. #### How it treats deploys and maintenance Every service has planned work and deploys that fail for a minute. Check that you can schedule maintenance windows, so planned work is not counted as downtime. Check that short deploy-time failures can be filtered out without slowing alerts for real outages. The guide to false alarms during deploys shows what to look for. #### Where alerts go Email plus the chat tool your team lives in: Slack, Teams, Google Chat or Discord. A webhook option means you can connect anything else later. Check that the recovery arrives in the same place as the alert. #### The status page Can it run on your own subdomain? Can it be password-protected for one customer? Does it explain outages, or just list them? Does it let people subscribe? #### Who can use it Several logins with roles beat a shared password. Look for a way to alert people who need to know about outages, such as a manager or a client, without giving them a login. #### How it will end Freshping's shutdown is a reminder that free products disappear. Prefer a tool whose business model you understand, and keep your own list of what you monitor. In Upcertain, the REST API returns every monitor. ### Keep a written list Whatever you choose, write down every URL, what counts as up for it, who should hear when it fails and which status page it belongs on. That list is what you rebuild from next time, and it makes the move itself take an afternoon. The step-by-step move into Upcertain, including CSV import, is on the Freshping page. ### Where Upcertain fits Upcertain is in early access, so there are no prices yet and accounts start on the Basic plan: 10 monitors as often as every 60 seconds and one status page. It covers HTTP, keyword, ping, port, SSL and heartbeat checks, alerts to email, Slack, Teams, Discord, Google Chat and webhooks, and status pages with custom domains on Team and Business. It checks from one region and has no phone or SMS alerts. If you need those, choose accordingly. The details are on the Freshping comparison page. ## Monitoring a Next.js app on Vercel: health route, keyword check and cron heartbeats Source: https://upcertain.com/blog/monitor-nextjs-on-vercel Vercel keeps the platform up. Whether your app works, whether the database behind it answers and whether your scheduled functions run is still your job. Here is a setup that covers all three. ### 1. Add a health route that does real work A static page proves the CDN answers. A health route proves the app can reach what it depends on. Keep it small, uncached and free of customer data: // app/api/health/route.ts import { db } from "@/lib/db"; export const dynamic = "force-dynamic"; export async function GET() { try { await db.query("select 1"); return Response.json({ status: "ok" }, { headers: { "cache-control": "no-store" } }); } catch { return Response.json({ status: "error" }, { status: 503 }); } } force-dynamic makes sure the route runs on every request. Next.js 14 and earlier rendered such GET handlers once at build time, which would make the check meaningless. ### 2. Monitor it Monitor | Target | Settings Keyword | https://yourapp.com/api/health | Must contain "status":"ok", every 30 s or 1 min HTTP | https://yourapp.com/ | Expected 200, every 1 min Keyword | Your sign-in page | Must contain a label that only renders when it works Every HTTPS monitor also checks the certificate and warns before expiry, which covers the custom domain on your Vercel project. Monitor the production domain, not *.vercel.app preview URLs, which change with every deploy. ### 3. Heartbeats for Vercel cron jobs Vercel runs scheduled functions from the crons list in vercel.json by calling a path in your app. Hourly schedules like the one below need a paid Vercel plan; on Hobby, crons run at most once a day. If the function throws, times out or the schedule is removed in a refactor, nothing tells you. Report in at the end of the handler: // vercel.json { "crons": [{ "path": "/api/cron/sync", "schedule": "0 * * * *" }] } // app/api/cron/sync/route.ts export async function GET() { await syncEverything(); await fetch(process.env.UPCERTAIN_HEARTBEAT_URL!, { signal: AbortSignal.timeout(10_000) }); return Response.json({ ok: true }); } Create a heartbeat monitor with a one-hour period and some grace, and put its URL in an environment variable. If the sync stops running or starts failing before the last line, the heartbeat stops and you hear about it. ### 4. Tune for serverless - Cold starts: the first request after a quiet period can be slow. A 10 to 15 second timeout avoids false failures without hiding real hangs. - Deploys: Vercel switches traffic to the new deployment when it is ready, so deploys rarely fail checks. If yours do, add a confirmation check. - Protect the cron route: when CRON_SECRET is set, Vercel sends it as Authorization: Bearer ; check it so only Vercel can trigger the job. The heartbeat call itself needs no secret. ### 5. Tell users Put the app, the API and the scheduled work on a status page at status.yourapp.com. When something fails at 3 a.m., users find the answer there instead of in your inbox. #### Should the health route check every dependency? Check what the app cannot work without, usually the database. Checking optional services such as analytics turns their outages into yours. #### Can I monitor preview deployments? You can, but their addresses change with each deploy. Monitor production, and run your tests against previews instead. #### How often should the health route be checked? Every 30 seconds to 1 minute for an app customers pay for. Each check is one small database query, which most databases will not notice. ## Monitoring a Supabase-backed app: what to check and how Source: https://upcertain.com/blog/monitor-supabase-app Upcertain itself runs on Supabase, so this is the setup we think about every day: watch the path your users take, the database connection your servers use, and the scheduled jobs inside Postgres. ### Check through your own app first Supabase publishes its own status page for the platform. What it cannot tell you is whether your app can read its data: an expired key, a broken row-level security policy or a migration that locked a table all look fine from the outside. Expose a small health endpoint in your app that runs one cheap query through the same client your users go through, and monitor it with a keyword check: import { createClient } from "@supabase/supabase-js"; export async function GET() { const supabase = createClient(process.env.SUPABASE_URL!, process.env.SUPABASE_ANON_KEY!); const { error } = await supabase.from("plans").select("id").limit(1); return error ? Response.json({ status: "error" }, { status: 503 }) : Response.json({ status: "ok" }); } Query a table that anonymous users may read, so the check needs no secret key and exercises the same policies as your app. ### Check the database connection your servers use Server-side code and workers usually connect to Postgres through Supabase's connection pooler. A port monitor on the pooler's host and port tells you the shared pooler accepts connections. It is shared by many projects, so only your health endpoint proves your own database answers. Use the host and port from your project's connection settings. ### Heartbeats from pg_cron If you schedule work inside the database with pg_cron, such as cleaning old rows or refreshing materialised views, a failing job only shows up in cron.job_run_details, which nobody reads. With the pg_net extension the database can report in after the job: select cron.schedule( 'nightly-cleanup', '0 3 * * *', $$ delete from events where created_at < now() - interval '90 days'; select net.http_get('https://upcertain.com/api/heartbeat/'); $$ ); Both statements run in the same job, so a failing delete stops the heartbeat. Create a heartbeat monitor with a 24-hour period and an hour of grace, and you hear if the cleanup ever stops. ### What we watch for Upcertain Our own public status page shows three services: the website, the dashboard and the API with the MCP server. The website and dashboard are checked with keyword and HTTP monitors. The API check sends an unknown key and expects 401, an answer that needs the database, so a database problem shows up as the service our users would notice. ### A short checklist - Keyword monitor on a health endpoint that queries Supabase through your app. - Keyword monitor on the sign-in page, since auth failures hurt most. - Port monitor on the pooler, if servers connect directly. - Heartbeat per pg_cron job and per external worker. - Certificate warnings on your own domains; Supabase's domains are Supabase's to renew. #### Should I monitor Supabase's own endpoints directly? Your own health endpoint is more useful: it fails for the reasons your users would notice, including your keys and policies, not only when Supabase is down. #### Does pg_net wait for the heartbeat request to finish? No. pg_net sends requests asynchronously, so the job does not slow down. A failed request is recorded in pg_net's response table, and the missing heartbeat alerts you anyway. #### What interval suits a database-backed health check? Every 30 seconds to 1 minute. Use a query that touches an index, such as selecting one row by key, so the check stays cheap. ## Heartbeats for systemd timers, Kubernetes CronJobs and queue workers Source: https://upcertain.com/blog/heartbeats-for-systemd-kubernetes-and-workers The crontab one-liner is easy. Scheduled work increasingly runs elsewhere: systemd timers, Kubernetes CronJobs, long-running workers. Here is where the heartbeat goes in each. ### systemd timers Put the heartbeat in the service unit, not the timer. For a Type=oneshot service, ExecStartPost= runs only after ExecStart= has finished successfully, which is exactly when you want to report in: # /etc/systemd/system/backup.service [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 3 https://upcertain.com/api/heartbeat/ ### Kubernetes CronJobs A CronJob can miss its schedule without any error you would see: the controller skips runs it could not start within startingDeadlineSeconds, concurrencyPolicy: Forbid skips runs while the previous one is still going, and a suspended CronJob does nothing at all. A heartbeat at the end of the container's command catches all of these: apiVersion: batch/v1 kind: CronJob metadata: name: export spec: schedule: "15 * * * *" concurrencyPolicy: Forbid jobTemplate: spec: template: spec: restartPolicy: OnFailure containers: - name: export image: registry.example.com/export:1.4 command: ["sh", "-c", "/app/export && wget -q -T 10 -O /dev/null \"$HEARTBEAT_URL\""] env: - name: HEARTBEAT_URL valueFrom: secretKeyRef: { name: upcertain, key: export-heartbeat } Keep the URL in a Secret: anyone with it can report in for the job. Use wget or curl, whichever the image has. ### Queue workers and daemons A worker runs continuously, so there is no end of the job to report. Report from the main loop instead, about once a minute, and only while the loop is healthy: let lastBeat = 0; while (running) { const job = await queue.next({ timeoutMs: 5_000 }); if (job) await handle(job); if (Date.now() - lastBeat > 60_000) { lastBeat = Date.now(); fetch(process.env.HEARTBEAT_URL!, { signal: AbortSignal.timeout(5_000) }).catch(() => {}); } } Report even when the queue is idle, so an idle worker is not mistaken for a dead one. Set the monitor's period to the reporting interval and a grace of one or two intervals. If the loop hangs on a stuck job, the heartbeats stop and you hear about it. ### Windows Task Scheduler & C:\jobs\import.ps1 if ($LASTEXITCODE -eq 0) { Invoke-WebRequest -UseBasicParsing -TimeoutSec 10 'https://upcertain.com/api/heartbeat/' | Out-Null } ### One monitor per job Give every job its own heartbeat monitor, named after the job. An alert that says "export stopped" is actionable; one that says "something in the cluster stopped" is not. Period and grace guidance is in the dead man's switch guide, and the basics are in the heartbeat setup docs. #### What if the job runs on several machines? Give each machine's job its own heartbeat monitor if each must run, or one shared monitor if any single run is enough. A shared monitor only notices when all of them stop. #### Should failures send a signal too? Heartbeats only signal success. To hear about a failure before the deadline, have the job report errors to your error tracker as well; the heartbeat still covers jobs that never run. #### What grace should a Kubernetes CronJob get? Enough for image pulls and scheduling delays on a busy cluster, plus the job's longest normal run time. Start with the run time plus 10 minutes and tighten it after a week. #### Does the heartbeat URL need authentication? No. The token in the URL identifies the monitor, so treat the URL as a secret and keep it out of images and repositories. ## Slack alert fatigue: how to keep an alert channel worth reading Source: https://upcertain.com/blog/slack-alert-fatigue Every team has seen it: an alerts channel so busy that people mute it, and then an outage sits in it unread for forty minutes. Alert fatigue is a configuration problem more than a people problem. ### Where the noise comes from - Unconfirmed failures: one dropped request, one alert. - Every event as its own message: down, still down, still down, flapping up and down. - Everything in one channel: the marketing site, staging and the payment API side by side. - Cascades: one shared dependency fails and twenty monitors alert separately. - Alerts nobody can act on: sent to people who do not own the service. ### Rule 1: confirm before you post Re-check before an incident opens. One confirmation check after 15 seconds removes most single-request blips; services whose deploys fail for a minute need a longer window. The confirmation guide has the arithmetic. ### Rule 2: one incident, two messages An outage should produce a down message and a recovery message in the same channel, and nothing else unless someone asks for reminders. Upcertain posts reminders only when you set a repeat interval, and acknowledging the incident stops them on every channel. ### Rule 3: route by owner Create one channel per team or per service area and let each monitor pick its channels. The payments team sees payments alerts; the web team sees the website. Staging monitors go to a quieter channel, or to email only. ### Rule 4: group cascades When a database or DNS provider fails, everything behind it fails within a minute. Alert grouping turns that into a single message listing every affected monitor, so the first responder sees the shape of the problem instead of scrolling. ### Rule 5: delay where speed does not matter Not every channel needs to hear at once. Keep the on-duty channel immediate and delay a wider channel by a few minutes; short blips resolve before the delayed alert is due, and the wider group only hears about real outages. ### Rule 6: make each message self-explanatory A good alert answers what, since when and why in the first line: "Down: payments-api, HTTP 503, since 09:13". It links to the incident and the place to acknowledge. Upcertain's Slack alerts carry the cause, the start time and buttons to acknowledge or view the incident. ### A monthly check-up 1. Count the alerts in the channel last month and how many needed action. 2. For every alert that needed none, change one setting: confirmation, delay, routing or the monitor itself. 3. Delete monitors for things nobody would fix. A channel where most messages need someone to act is a channel people keep reading. That is the whole goal. #### Should staging alert at all? Yes, but somewhere quiet: a separate channel or email. Staging failing is useful to know, not urgent. #### Are threads better than separate messages? Upcertain posts the recovery as a new message in the same channel, so it shows in the channel's list without opening a thread. ## An error budget for small teams: spending your 43 minutes a month Source: https://upcertain.com/blog/error-budget-for-small-teams An uptime target is easier to live with as a budget. At 99.9% a 30-day month allows 43 minutes 12 seconds of downtime. The question is what you spend it on. ### From target to budget Target | Budget per 30-day month | Per week 99.5% | 3 h 36 m | 50 m 24 s 99.9% | 43 m 12 s | 10 m 5 s 99.95% | 21 m 36 s | 5 m 2 s 99.99% | 4 m 19 s | 1 m 0.5 s The uptime calculator works out any other target and period. ### What spends the budget - Deploys that fail briefly. Twenty deploys a month that each fail for 60 seconds spend 20 minutes, almost half of a 99.9% budget. - Incidents. One 30-minute outage spends most of the rest. - Slow detection. The minutes between failure and someone noticing count too. A 5-minute check interval can cost several minutes per incident before anyone starts work. - Maintenance, unless your target excludes planned windows. ### Measure it You need two things: monitoring that sees short failures, and incidents that start at the first failure rather than the moment someone noticed. Check every 30 seconds to 1 minute so 1- and 2-minute outages are counted at all; see check intervals. Upcertain records each incident from the first failed check and reports uptime over 24 hours, 7, 30 and 90 days. Confirmation checks keep short failures from alerting anyone, and failures that never become incidents do not open an incident record. If you want deploy blips in the budget, look at the monitor's check log as well as its incidents. ### Spend it on purpose 1. At the start of the month, the whole budget is available for shipping. 2. When an incident spends more than half of it, slow down risky changes until the end of the month. 3. When the budget is gone, ship only fixes that make things more reliable. 4. When a month ends with most of the budget unspent, you can afford to move faster, or promise customers a higher target. ### Make deploys cheaper For most small teams the cheapest minutes to win back are deploy minutes: rolling restarts, readiness checks and connection draining. The deploy guide lists them. ### Publish what you promise Whatever target you choose, a status page with real uptime history keeps you honest with customers and with yourselves. It is harder to argue that last month was fine when the bars say otherwise. #### Does maintenance count against the budget? That depends on what you promise. Many SLAs exclude announced maintenance. In Upcertain, time inside a maintenance window counts as maintenance, not downtime, so it does not lower the uptime figures. #### What if one service has a different target? Give each service its own target and budget. A marketing site at 99.5% and a payment API at 99.95% spend very differently. #### Should we share the budget with customers? Share the target and the real uptime history on your status page. The budget itself is an internal tool for deciding when to slow down. ## Incident communication templates for small teams Source: https://upcertain.com/blog/incident-communication-templates During an outage nobody wants to write prose. These templates are short on purpose: fill in the brackets, publish, and get back to fixing. ### Investigating Title: [Service] errors We are investigating errors on [service]. Some customers may be unable to [action people cannot do]. Next update by [time, time zone]. Publish this within 10 to 15 minutes of confirming customers are affected, even before you know the cause. ### Identified We have found the cause: [plain description, e.g. a database server ran out of disk space]. We are [fix in progress]. [Service] remains [degraded / unavailable]. Next update by [time]. ### Monitoring A fix is in place and [service] is working again. We are watching it closely. If you still see problems, please contact [support address]. ### Resolved This incident is resolved. Between [start] and [end] ([duration]), [what customers experienced]. The cause was [plain cause]. We are [one change to prevent it]. We are sorry for the disruption. ### Degraded, not down Title: Slow responses on [service] [Service] is working but slower than usual, and some requests may time out. Your data is safe. We are [what you are doing]. Next update by [time]. Use this when the service works for most people but not well. Saying it plainly stops customers from assuming the worst and opening tickets. ### Scheduled maintenance Title: Scheduled maintenance on [service] On [date] from [start] to [end] [time zone], [service] will be [unavailable / read-only / slower] while we [work]. [What customers should do, if anything.] ### Post-incident note What happened: [two sentences] Impact: [who, what, how long] Timeline: [detected, acknowledged, fixed, resolved] Cause: [plain cause] What we are changing: [one to three items, with owners] ### Rules that make them work - Say what customers notice, not your internals: "checkout fails", not "pod eviction on node-7". - Always give the next update time, and keep it even if there is no news. - Use the same time zone in every update, and name it. - Never guess the cause in public; "we are investigating" is honest. - Apologise once, in the resolved update. ### Publishing them in Upcertain From an incident, use Post status update to publish to the status pages that show the affected monitor; subscribers receive it by email. Maintenance notices go out as announcements of the type Maintenance, and planned windows appear on the page ahead of time. See subscribers and incident response for small teams. #### How often should we post updates? Every 30 minutes during a major outage, or at whatever interval you promised in the last update, even if the only news is that you are still working on it. #### Who should write the updates? Someone other than the person fixing the problem, if you have two people. The person fixing it should not also be writing to customers. #### Should we email subscribers for every update? For incidents customers notice, yes: investigating, resolved, and any update that changes what they should do. Short incidents that resolved before anyone noticed may only need the resolved note on the page. #### What should the resolved update avoid? Blame, guesses and internal jargon. Say what customers experienced, for how long, the cause in plain words and one thing you are changing. ## Status 200, still broken: catching silent failures with keyword checks Source: https://upcertain.com/blog/keyword-monitoring-silent-failures The most frustrating outage is the one your monitor calls healthy. The server answered 200; the page said "Something went wrong". Here are the patterns we see most, and the keyword check that catches each. ### Why 200 is not enough A status code reports what the server decided to send, not whether the page works. Error handlers, caches, CDNs and front-end frameworks all produce friendly pages with status 200. To a status-code check they look exactly like success. ### Six silent failures and their keywords Failure | What the page shows | Keyword check Application error page | "Something went wrong" | Must not contain Something went wrong Maintenance page left on | "We'll be back soon" | Must not contain be back soon Empty listing | A page with no products | Must contain a product or category name that is always listed Sign-in broken | The form renders without its fields | Must contain the label of the email field Dependency down | Health JSON with a failing part | Must not contain "database":"down" Cached error page | A CDN or cache serving a stored error page with status 200 | Must not contain the error page's heading ### Must contain beats must not contain A must-not-contain check only catches the error text you predicted. A must-contain check catches every failure that removes the text you expect, including ones you did not imagine. Use must-contain on the most important page and add must-not-contain checks for the error pages you know about. ### Keeping keyword checks honest - Pick text that only appears when the page works. Your brand name is on the error page too. - Avoid text that changes: prices, dates, rotating banners, A/B-tested headlines. - Remember that the check reads the HTML the server sends, before JavaScript runs. - When a redesign changes the text, update the keyword in the same release. - Keep the status-code rule as well: both must pass. ### Health endpoints make it easy For your own applications, the cleanest keyword check is a health endpoint that returns JSON describing its dependencies. A must-contain check for "status":"ok" fails on any dependency failure you wire into it, and the alert names the cause as a missing keyword. ### In Upcertain Keyword monitors search the first 1 MB of the response, match without case unless you ask, and accept phrases of up to 500 characters. Setup is in the keyword monitor docs; the product view is keyword monitoring. #### Should keywords be case-sensitive? Usually not. Case-insensitive matching survives small copy edits; turn case sensitivity on only when the exact form matters. #### What if the page is rendered by JavaScript? Check a server-rendered page or an API response that carries the same information. Keyword checks read the HTML the server sends, before scripts run. #### How many keyword checks should a site have? One must-contain check on each page that matters to the business, plus a must-not-contain check for the error page your platform shows. #### Do keyword checks cost more than HTTP checks? In Upcertain each counts as one monitor, the same as an HTTP check.