Changelog
What shipped, and when
Uptimely is a hosted service deployed continuously, so changes reach your account the day they are finished — there is no release to install or upgrade to. This page records the ones you can see. Last updated Sep 2, 2026.
For what the product does today rather than what changed, read what’s live. Changes to this website and to the documentation are not listed here; this is the product.
September 2026
| Date | Change | What it means |
|---|---|---|
| Heartbeat monitors for cron jobs and scheduled work | Give a scheduled job a Uptimely heartbeat URL to call when it finishes. Set how often you expect to hear from it and how long to wait past that before worrying, and a job that stops checking in raises an incident and pages exactly like a website going down. Backups, nightly imports and queue workers can now be monitored by their silence. | |
| The Free plan now includes three team members | Up from two. Monitoring is a team activity and two seats was not a team — the third seat is free on every existing Free project, with nothing to do to claim it. | |
| The signup prompt waits until you have built something | Trying Uptimely without an account used to raise a "create your account" prompt before you had made anything worth saving. It now appears after you create your first monitor or status page, and never interrupts you while an incident is on screen. |
August 2026
| Date | Change | What it means |
|---|---|---|
| Monitors alert only after repeated failed checks | Every monitor now waits for two consecutive failed checks before declaring an incident, instead of paging on the first one. You can set the threshold per monitor from 1 to 10. Uptime data is unchanged — a single failed check still counts as downtime and still shows on your status page; it just no longer wakes anyone. | |
| A stalled handshake is no longer read as an outage | When a connection opens but the TLS handshake never completes, the check now records that the site was never actually reached, rather than treating a timeout as proof the site is down. This closed a run of false incidents caused by network interference on the path to the monitored site. | |
| Response-time charts and a time range on public status pages | Visitors can narrow the uptime history to 7, 30 or 90 days — within whatever window you publish — and each component with its heartbeat strip turned on opens to a response-time chart. Only successful checks are plotted, and gaps break the line instead of drawing a straight, reassuring line through an outage. | |
| Check now | A button on the monitor page runs the check immediately, instead of making you wait out a full polling interval to find out whether you configured it correctly. It is the ordinary check, not a dry run, so the result counts. | |
| The REST API can change and remove things, not just create them | Monitors can be updated and deleted, and status pages can be created, updated, deleted and have their components attached and detached, all under a new status-pages:write scope. The dashboard and the API now run the same code, so the two cannot drift. | |
| Acknowledge and resolve incidents from Slack | Incident messages carry the full action set again — view, execute on-call, acknowledge, resolve, change state and add a note — so a page can be handled without leaving the channel. The buttons and their dialogs had been built for months and were reachable by nobody. | |
| Slack and Discord messages say more, and say it once | Alert cards now carry the severity, the affected monitor, the cause, and — on resolution — how long the service was down. Each event posts one card instead of a card preceded by a plain-text copy of itself, and a resolved incident no longer claims it was created at the moment it was resolved. | |
| Custom status-page domains from one hostname | Add a custom domain by typing the whole hostname. Uptimely works out the parent domain for you, reuses one you have already proved rather than asking for it twice, and walks you through the DNS record in a guided flow — there is no separate domain-registration step to finish first. | |
| Mute a monitor for a deploy window | Silence one monitor's alerts until a time you choose, without pausing its checks. Uptime, heartbeats and the status page stay truthful throughout, open incidents still resolve themselves, and every suppressed alert is written to the monitor's feed so the quiet is never a mystery. | |
| Monitor dependencies | Tell Uptimely that a monitor sits behind another one, and it stops paging you about the children when the parent is down. One outage becomes one page instead of fifteen. | |
| Criteria can be judged over a window instead of one check | A criteria filter can require a condition to hold across the last few minutes — any value, all values, or an average, maximum, minimum or sum over the window — rather than reacting to the check that just ran. A window that cannot be read is never treated as a breach. | |
| One workspace message per monitor event | A monitor going down used to post twice to the same Slack or Discord channel: once for the status change and once for the incident it declared. Now the incident message carries the event, and the status-change post is dropped only where that channel is proven to be receiving the incident. Discord also honours notification rules, which previously narrowed Slack and nothing else. | |
| Deleting a project stops its monitors | A deleted project used to disappear from the dashboard while its monitors kept being probed, its incidents kept paging, and its status page kept serving. Deleting a project now removes its monitors, incidents, alerts, maintenance windows, status pages, subscribers and on-call policies together. | |
| Certificates for custom status-page domains, handled for you | A status page on your own domain now gets its TLS certificate issued and validated as soon as the DNS record is in place. There is no manual certificate step and nothing to renew — the page is served over HTTPS from the moment the domain resolves. | |
| Images can be taken down, not just replaced | Status-page logos, covers and favicons gained a remove control beside the current file, and removing or replacing any image now stops the old one being served at its address. Uploaded profile pictures also appear where people appear — the app header, the account menu, and the owners lists. | |
| Documentation at getuptimely.com/docs | A developer documentation site with a native API reference, the OpenAPI specification, and a page for every error the API can return — so a machine-readable error type in a response body resolves to a page a human can read. | |
| Drag-and-drop file uploads everywhere | Profile pictures, status-page logos, covers, favicons and the subscriber CSV import all use the same drop zone, with size and file-type limits stated up front rather than after a failed upload. | |
| Outbound webhooks | Point Uptimely at your own endpoint and get signed, retried deliveries for incidents, alerts and monitor status changes. Signatures follow the Standard Webhooks specification, secrets can be rotated without downtime, and every delivery attempt is visible. | |
| The @uptimely/sdk package | A typed TypeScript client for the whole /v1 surface, published on npm, with a helper for verifying webhook signatures. | |
| Public REST API with OpenAPI and scoped keys | A versioned /v1 API for monitors, incidents, alerts, status pages and on-call, described by a published OpenAPI 3.1 document. Keys are scoped, hashed at rest, and issued separately for live and test use; errors follow RFC 9457, so failures arrive as structured problems rather than prose. | |
| Per-user notification settings | Every person on a project chooses which of the 31 event types reach them, and on which of email, SMS and push, from one grid. Existing members were seeded with sensible defaults rather than being switched off. |
July 2026
| Date | Change | What it means |
|---|---|---|
| A real notification inbox | The bell in the top bar is now a per-user inbox: read and unread state lives on your account instead of in one browser, invitations and new incidents arrive in it, and mobile devices can be registered for push. | |
| Per-monitor request timeout | Website and API monitors take a request timeout, defaulting to 30 seconds and settable from 1 to 60. Slow-but-alive endpoints no longer have to share one fleet-wide number with fast ones. | |
| Three defences against false down alerts | A monitor about to be declared down is re-checked before the flip commits; a network-level failure only counts if the prober can prove its own connectivity at that moment; and the prober now prefers IPv4 with a connection budget below the request timeout. Recoveries are never delayed by any of this. | |
| The interface tells you what happened | Destructive actions confirm, and the dangerous ones ask you to type the name. Form errors appear next to the form instead of replacing the page. Buttons show they are working. Empty screens explain whether there is nothing yet or nothing matching your filter. Timestamps read as "12 minutes ago" with the exact time on hover. | |
| Custom domains for status pages | Serve a status page on your own hostname through a guided setup flow that places the DNS record for you, with a manual CNAME path when you would rather do it yourself. | |
| Annual billing, and ten monitors on Free | Pro can be paid annually for the price of ten months. The Free plan's monitor limit doubled from five to ten at the same time. | |
| Response-time chart on the monitor page | The Metrics tab plots each monitor's response time over its recent checks, so a service getting slower is visible before it becomes a service that is down. | |
| Support requests and copilot feedback | A support form on the site routes to a real inbox with a reference you can quote, and copilot answers take a thumbs up or down that reaches the people who tune it. | |
| The AI copilot | Ask about your monitors, incidents and telemetry in the app, with ⌘I or from the command palette. It works from the same permissions you have, and every change it wants to make is shown to you for approval before it runs. | |
| Connect an AI agent over MCP | A remote MCP endpoint with OAuth means Claude and other MCP clients can read your project — and, if you switch write operations on, act in it. Connected apps are listed in your settings and can be revoked there. | |
| Trial reminders and plan-limit warnings | Emails three days and one day before a trial ends, and a warning as you approach a plan limit instead of an error the moment you cross it. | |
| Notification settings became a grid | Owner notification preferences were a list you had to add rows to, which hid the events you had never added. Every event is now a row, every channel a column, and a cell saves the moment you toggle it. Channels with no verified contact method are marked as undeliverable rather than silently accepting a preference that would never fire. | |
| The heartbeat strip on monitors is live again | Individual check results are recorded on every sweep again, so the bar of recent checks on a monitor reflects what actually happened rather than freezing at an old date. | |
| Acknowledging an incident anywhere stops the escalation | Acknowledging from the dashboard, an email, or Slack now stops the on-call policy from escalating to the next person, wherever the acknowledgement came from. | |
| Prometheus metrics endpoint | A /metrics endpoint exposes monitor status and response times in Prometheus format, so Uptimely's data can sit alongside the rest of your dashboards. |
Entries cover customer-visible changes only, dated by the day they reached production. Work that shipped switched off — anything waiting on infrastructure that is not running yet — is deliberately left out until it is actually doing something for you. Something here look wrong? Email support@getuptimely.com.