Changelog

What's new.

Every change to how Sentinel checks your sites and how you hear about it, dated the day it shipped. The big ones also go out by email.

15 changessince October 2026

November 2026

Free tools

Is It Down pages show reachability per region

The public Is It Down pages for popular services now read from live monitors. Each page shows the last 24 hours of reachability from every one of the fifteen regions and the incidents of the last 30 days, so "is Stripe down?" gets an answer per region rather than a single yes or no.

Twelve infrastructure services joined the set: Stripe, Cloudflare, AWS, Vercel, Netlify, Shopify, Twilio, SendGrid, Supabase, Fly.io, DigitalOcean and Linode. The checks behind these pages run every five minutes from a dedicated account, separate from any customer's monitors.

October 2026

Integrations

n8n integration with two importable workflows

Sentinel now has an n8n integration page and a docs section covering both directions: incidents and recoveries flowing into n8n through webhooks, and n8n calling the Sentinel API.

Two workflows are ready to import. The first routes incidents and recoveries into Slack, or any destination you swap in. The second runs every Monday, reads your team roster and flags anyone without MFA or a recent sign-in. Nothing extra to install in n8n.

Monitoring

Bearer tokens on the monitor form, request data encrypted at rest

HTTP Authentication is its own card on the monitor form, right below the URL, with a Bearer token option alongside basic auth. It used to sit at the bottom of the collapsed advanced settings. The Terraform provider, the CLI and the MCP server accept the same bearer auth type.

Custom request headers and request bodies are now encrypted at rest in the database, and neither is included when a monitor is serialized for the dashboard list.

Alerts

Alerts name the layer that failed

When a check fails, the incident now says where it stopped: DNS resolution, the TLS handshake, the TCP connection or the HTTP response itself. The same verdict appears in the alert and on the incident page.

A bot filter or WAF that rejects the checks is reported as a diagnosis, not a downtime. The alert says the checks were refused, lists the regions still reaching the target and the status each one got, so you can allow the probe IPs instead of chasing an outage that isn't one.

Monitoring

JSON assertions check arrays and typed literals

A JSON "contains" assertion on an array now checks membership, so scopes contains mail.send passes when mail.send is one of the values. Until now contains and not contains searched strings only.

"Equals" and "not equals" match a JSON true, false or null against the literal typed in the form, so a boolean field can be asserted directly instead of through a string comparison.

Monitoring

Certificate details come from every HTTP check

Every region's HTTP check already completes a TLS handshake with your host, so the certificate's issuer and expiry are now recorded from that handshake on each check. Expiry warnings are as current as the last check rather than a separate daily pass.

The standalone certificate check stays in place as a fallback for monitors that have no HTTPS check of their own. The SSL certificate monitoring page describes what is recorded and when the warnings go out.

Monitoring

Regions take turns within each interval

Checks from the fifteen regions are spread across each interval instead of landing on your site at the same moment. The regions run about a second apart, so a one-minute monitor still gets fifteen checks a minute, never as one burst.

The interval line on the monitor form describes the load this puts on a site. A manual check follows the same spread and arrives from every region within a few seconds.

Alerts

Alerts say how many regions confirmed the outage

Down alerts now say how many regions confirmed the outage. The email reads "Confirmed from: 8 of 15 regions" with the regions named, the in-app alert says "unreachable from 8 of 15 regions", and the Slack, Discord, Teams and Telegram messages carry the same line. Webhook payloads for monitor.down include status.confirmed_regions.

The rule behind the count is published at How Sentinel confirms outages: an outage needs at least half of the regions a monitor uses, three or more, on two continents, before anyone is alerted.

Monitoring

Manual checks run everywhere and count toward incidents

A manual check used to be a one-off read from a single region that never touched incident state. Now "check now" from the dashboard, the API, the CLI or the MCP server's trigger-check tool runs the monitor from every region it uses, through the same path a scheduled check takes, so it can open an incident or close one.

Manual checks run at most once every 30 seconds per monitor. A second request inside that window is told how many seconds to wait.

Security

Security hardening across the web app, API and connector

A pass over the web app, the API and the OAuth connector used by AI assistants. Role checks are enforced on every web route that changes team data, matching what the API already did. Webhook endpoints are vetted the same way monitored URLs are: the host must resolve to a public address, the connection is pinned to the vetted IP and redirects are re-checked hop by hop.

The connector's dynamic client registration accepts redirects only to the assistants it supports, and every sign-in path, including the native mobile flow, honours two-factor authentication before a token is issued.

Account

Signup starts with the site you want monitored

The register page asks for the site you want monitored before anything else. The first monitor is created with the account, so the dashboard opens with a check already running instead of an empty state.

The URL survives a Google or GitHub sign-up too: it is carried through the provider redirect and the monitor is created when the account is.

Dashboard

Dashboard dark mode takes the carbon palette

The dashboard's dark mode moved to the carbon palette from the public site: a deeper page ground, darker cards and the status colours as the only chromatic accents. The two now read as one product when you move between them.

On the network status card the fifteen region pills sit in a row under the map instead of floating over it, so the southern hemisphere stays visible.

Monitoring

Fifteen regions on six continents, on every plan

Every monitor now checks from fifteen regions on six continents: Ashburn, Chicago, Seattle, Toronto, Mexico City and São Paulo in the Americas. London, Frankfurt, Tel Aviv and Johannesburg across Europe, the Middle East and Africa. Mumbai, Singapore, Tokyo, Seoul and Sydney in Asia Pacific.

That is on every plan, Free included, and prices have not changed. The region picker on the monitor form is grouped by continent for monitors that should skip a region.

Plans

Checks every 15 seconds on Business, 30 on Pro

Pro monitors can now check every 30 seconds and Business monitors every 15 seconds. Both were a minute before. Free stays at every 5 minutes and Starter at every minute, so the ladder reads 5 minutes, 1 minute, 30 seconds, 15 seconds across the four plans. Every interval runs from every region the monitor uses.

Existing monitors kept their interval. Pick the faster one per monitor from the monitor form, or reply to any Sentinel email and I will switch them for you.

Monitoring

One probe for every region

The last six regions moved from the original PHP workers to the Go probe that the newer regions already ran, so all fifteen regions now run the same binary. Every check measures DNS, connect, TLS handshake and time to first byte the same way, and the response-time charts compare like with like across regions.

The engineering story is in I Replaced 50+ PHP Workers With One Go Process.

Every one of these is already on your account.

No account yet? Ten monitors from fifteen regions are free, and the first one takes about a minute.