What’s new in CuliPulse

Vendor status and DNS monitors no longer send false "can't check" alerts

Vendor status and DNS monitors could send a "can't check" alert, go quiet, then send it again, even though the status page or DNS lookup was working fine. The cause was on our side: the scheduler that runs these checks was sometimes delayed, and the monitor treated the missing reading as "can't check". These monitors now run their own check when the scheduled one is late, so they keep checking on time and only alert you that they can't check when the status page or lookup really can't be read.

Agent offline and online alerts now reach destinations set to specific monitors

When one of your own agents stops checking in or comes back, the alert now also goes to any destination set to Specific monitors that covers a monitor that agent checks. Before, only destinations set to All monitors were told, so a destination you had limited to the monitors on that agent stayed silent. Each destination still gets the alert once, and destinations that cover none of that agent's monitors are not alerted.

DNS "Discover records" no longer sets up checks that fail on healthy domains

When you click Discover records on a DNS monitor, addresses (A/AAAA) are now set to "just check they exist", because sites behind a CDN or geo-DNS answer with different addresses depending on where you ask. Before, these were saved as an exact match, which could alert that a healthy domain was down within minutes. A CNAME now checks the first name it points to, since the later steps of a CDN chain also change by location. TXT records now start unticked. Monitors you already created are unchanged; if one of yours alerts on changing addresses, switch its A/AAAA rule to present.

Incidents now start at the first failed check

When a monitor waits for several failed checks before alerting, the incident used to start at the check that confirmed the outage, so every outage looked one check interval shorter than it really was. On the Free plan that meant roughly 5 minutes missing from each incident. An incident now starts at the first failed check of the run of failures behind it. You still get the alert at the same moment as before, but the incident's duration, your uptime figures, the "down since" time in the alert and the since value in webhooks now cover the whole outage. The same applies to slow (degraded) incidents. Past incidents are not changed.

Let CuliPulse through your firewall

If a firewall, WAF, CDN or bot protection was turning away CuliPulse's checks, you can now allow them. The safest way is a secret header that only your monitor sends, and the docs walk you through it with a Cloudflare example. The shared locations' three fixed addresses are published too, for firewalls and cloud security groups. They're shared by every CuliPulse account, so allow only what the check needs. We'll give you 14 days' notice before any address changes. When a check gets HTTP 403 or 429, the monitor page now links straight to the guide.

Privacy Policy updated for website analytics

We now use Google Analytics on our public website and docs to see which pages help people find CuliPulse, and in the console to count sign-ups, new monitors and checkouts. Visitors from the EU, the UK and Switzerland are asked first, and nothing loads unless they accept. Anyone can change their choice at any time with "Cookie settings" in the footer. Inside the console we never record what you monitor. Details are in the Privacy Policy.

Send feedback or report a problem from the app

There's now a Feedback link at the bottom of the side menu. It opens an email to us with your workspace already filled in. Error messages that show a request id also have a Report link, so you can send us the details in one click. See the new help page in the docs for more.

Docker agents can now check services on the same machine

The Docker command for installing an agent now uses host networking (--network host), so the agent can check services running on the same machine, like a database or cache. Before, those checks failed with "Port closed or refused" even though the port was open, because inside the container that address meant the container itself, not your machine.

• New agents. Just copy the command from the agent's page. It already includes the change.
• Agents you installed earlier. Open the agent's page, choose Update this agent, then Generate update command. It recreates the container with a fresh token. Add back any extra -e settings you had added, such as network discovery.
• Docker Desktop (Mac, Windows or Linux). By default, host networking points at Docker's own virtual machine, so use host.docker.internal as the target to reach your own computer.

The install guide has a new section on checking services on the same machine.

API incident lists follow your plan's history

The two API endpoints that list incidents now show the same history as the console, which depends on your plan (see Plans). Before, they returned your latest 200 incidents whatever your plan.

• Still-open incidents always show, however long ago they started.
• Nothing is deleted. Older incidents come back if you upgrade.
• The API reference now documents the plain-words reason (symptom) that each location reports when its latest check fails.

Clearer billing while a payment is still processing

If your first card payment takes a few minutes to confirm, the Billing and Plans pages now say so in plain words ("Payment pending") instead of showing buttons that can't work yet. Your plan switches on by itself once the payment clears. The "Payment received" message on Billing now only says your new plan is active once it really is.

Clearer messages when a form needs fixing

When something is missing or not accepted, the form now tells you exactly which field it is, in plain words, and moves you straight to it. This covers adding and editing notification destinations, creating a report, enrolling an agent and requesting a new channel. The Create report button no longer sits greyed out without explanation, and when we can't save something because of a problem on our side, the message now includes a reference you can quote to support.

Clearer messages when AWS rules and agent settings need fixing

On the AWS adoption rules page, the Save rules button is no longer greyed out without explanation. If a rule is missing a tag name or a monitor type, Save shows the message right under that field and takes you to it. The network range field on an agent now tells you in the same way when a range can't be scanned. And when generating an agent update command, regenerating a heartbeat check-in URL, or saving rules fails on our side, the message is now in plain words and includes a reference you can quote to support.

Cloud discovery cleans up properly, and new rules no longer guess a monitor type

A new rule in the cloud discovery rule builder no longer starts with a monitor type already chosen. You pick the type yourself, and the rule can't be saved until you do.

Monitors made from discovered resources are more accurate. A tag whose value is https now gives an https monitor, even on a load balancer that also listens on port 80. If a resource's address already starts with http:// or https://, the port from your rule is added to it, and IPv6 addresses are written in square brackets. Auto-adopt now only picks up resources that the agent's latest scan actually saw.

With the next agent version, one missing AWS permission or one region that isn't enabled no longer stops clean-up everywhere else. The agent reports which services and regions it read successfully, and resources that disappeared from those are closed as before. Very large AWS accounts are also scanned more reliably: a slow scan stops cleanly instead of flooding the agent page with errors, and a single load balancer whose tags can't be read no longer hides up to 19 others.

The cloud discovery guide now notes that EC2 instances without a matching rule get a ping check, which fails if your security group blocks ping.

Plainer wording in the console

A handful of labels and notes in the console now say what they mean.

• Agents that stopped answering. The Overview shows "not responding" instead of "stale", the same words the Agents page uses.
• Monitors with no location. A monitor that has nowhere left to check from is labelled "No location".
• Old readings are flagged. On a paused monitor, or one with no location, the latency panel now says the last result may be out of date instead of calling it fast.
• Clearer history note. On a new monitor, the uptime note now reads "full 30-day history by" followed by a date, so it is clearly a date in the future.
• Revoking an agent. The summary reads "1 monitor uses this agent", and every count says what it counts.
• Error messages on a phone or tablet. The message that appears when a monitor can't be saved is easier to read, and no longer covers the Create and Cancel buttons.

Down alerts now tell you when only some locations are reporting

When a monitor checks from two or more locations and goes down while only some of them are reporting, the Telegram, Slack and email alert now adds one line saying so, for example "Only 1 of 3 locations is reporting (Frankfurt and Office NAS are silent) — this result may not reflect every location." That way you can tell a result seen by a single location from one every location agrees on. Alerts where every location is reporting look the same as before.

Clearer first minutes with a new monitor

A few things that confused people on their first day are now plainer.

• Why a new monitor is still "Pending". If its first check failed, the top of the monitor page now says why (for example "Couldn't connect — port closed or refused") and how many more failed checks it takes before you are alerted.
• Recent % on a brand-new monitor. With only a few checks so far, the monitors list shows a count such as "1/2" instead of a percentage that a single early failure would turn into an alarming 50%. The percentage returns after five checks.
• Agents count in the sidebar. It now counts only the agents you set up yourself, not the shared locations CuliPulse runs for everyone, and disappears when you have none.
• Unnamed webhooks. A webhook you haven't named is called "Webhook" instead of its web address. The address still shows on the row.
• Agent page after it connects. Once an agent is online, the install command folds away behind "Show install command" so the page leads with what the agent is doing.
• Unknown count on the Monitors page. Its note now reads "no recent result" instead of "awaiting checkpoint".

Choosing where a monitor checks from is easier to find

Choosing where a monitor checks from is now its own step in the monitor form, right under "What to watch", instead of being tucked inside the Alerts section.

• Always visible. You no longer have to guess where the location choice is hiding. It shows up when you create a monitor and when you edit one.
• Your agents first. Agents you run yourself are listed before the shared ones run by CuliPulse, which is what you want for private or internal addresses.
• Alerts stays about alerting. The Alerts section keeps how soon we alert you, what counts as healthy, and the option to only alert when more than one location fails.

Ping monitors now tell you when the address can't be pinged

A Ping monitor now checks the address you enter when you save it. Ping only works with a host name or an IP address, so something like db.example.com:80, user@host or a pasted web address used to be accepted and then show as down with no clue why. Now you get a short message right away explaining what to change, in the app and through the API.

• What works: a host name such as db.example.com or an IPv4 address such as 192.0.2.10. IPv6 addresses aren't supported for Ping yet.
• What doesn't: a port (ping has none), an IPv6 address, https://, a path, a login or a space.
• Your existing Ping monitors: nothing changes for them. A monitor you saved earlier keeps working, and you can still edit its name or interval. The new check only applies when you create a monitor or change its address.

A heads-up when a private address is checked from a shared location

The monitor form now warns you if a website, ping, port or UDP monitor points at a private name or address (like a name ending in .internal, or 192.168.1.10) while one of CuliPulse's shared locations is selected. Shared locations can only reach the public internet, so that combination would show as down even when your server is fine. The warning suggests using only your own agents instead.

Also: setting up an agent no longer asks which check types it may run, because the agent reports what it can do when it first connects. The Linux install command no longer includes the agent name, so names with spaces work, and the install command on the agent page now scrolls sideways instead of wrapping in the middle of a word.

The agent guides cover updating and removing an agent, and now say that agent offline and online alerts go only to destinations set to All monitors.

Reports can cover 100 or more monitors

A report that includes 100 or more monitors used to fail to load or save with an error. Large reports now work, including when they are shared by link. A report can include up to as many monitors as your plan allows.

A monitor can now go down when one of its locations is offline

If a monitor checks from two or more locations and one of them stops checking in, the monitor no longer waits for it. Before, a monitor set to "Only alert if more than one location fails" could stay up while your site was down, because the offline location could not agree. Now the locations that are still reporting decide, so one location on its own can mark the monitor down while the other is away.

The monitor page now says when this is happening, for example "Checking from 1 of 2 locations. Frankfurt hasn't checked in since 14:05", so you can tell that one location is deciding alone for now.

Deleting an agent also lowers a "confirm from N locations" setting to the number of locations that remain, so the monitor can still go down. The Revoke screen says which monitors keep running from their other locations, and the monitor form no longer claims that checking from several locations protects you from false alarms when only one has to fail.

A heads-up when your own agent can't use saved passwords or tokens

Agents you run yourself never receive your saved sign-in details, secret headers, secret request bodies or secret payloads, so a check from one of them runs without these. Until now nothing told you, and an authenticated endpoint just showed as down.

Now the monitor form shows a notice before you save when one of your own agents is selected and the monitor has saved secrets. The API answers a successful save with a warnings entry, and Terraform shows a warning on apply. The notice repeats on every save, and on every Terraform apply, while the combination stands. To check an endpoint that needs saved credentials, use a shared location. The agents and monitor type pages explain this.

Monitor internal IP addresses with your own agents

An HTTP monitor can now use a private IP address, such as http://192.168.1.10/ or http://10.0.0.5:8080/, when every location on the monitor is one of your own agents. Before, saving it was refused even with only your own agent selected, and the only workaround was a hostname.

If a shared location is also selected, saving is still refused, with a message that tells you to remove the shared locations or use your own agent only. Shared locations can never reach private addresses. This applies in the console, the API and Terraform.

A stopped agent no longer looks healthy

When an agent stops checking in, CuliPulse now says so everywhere instead of showing a calm page.

• Monitor page. A monitor that can't be checked shows Unknown with the reason: which agent stopped sending results and since when, with a link to it. The last reading is labelled as possibly out of date, so a fast old reading no longer reads "nothing to worry about".
• Agent page. An agent that missed a check-in or went offline no longer shows a green "Agent connected". It says it is not responding or offline, and what to check.
• Agents list. Offline agents now count in the attention banner and the summary, with a red outline on their card, and their location no longer counts towards Coverage. A late agent is now labelled "not responding".
• "Can't check" alerts. Telegram, Slack, email and webhook alerts name the agent that stopped checking in and when it was last heard from, so you can tell "my site is fine" from "CuliPulse can't see it". If the agent is a shared one run by CuliPulse, the alert says so, because there's nothing for you to fix. Webhook payloads have the same fields as before; only the reason text is more specific.

One broken destination no longer blocks or repeats your other alerts

Each alert destination is now delivered on its own. Before, if one destination failed (for example a Telegram chat where the bot was blocked, or a webhook answering with an error), the destinations after it could miss the alert, and the ones before it could get it up to four times, sometimes with an old "down" arriving after the "back up". Now a failing destination is retried by itself, and your other destinations get each alert once.

A Telegram chat that blocked or removed the bot is no longer retried, since retrying can't fix it. CuliPulse now also records when a destination last failed and why.

Slack and webhook destinations that answer "too many requests" (429) or "request timeout" (408) are now retried instead of dropped. When the answer says how long to wait (a Telegram rate limit, or a Retry-After header), CuliPulse waits that long before trying again, up to 5 minutes.

Clearer missed-heartbeat and slow-recovery alerts

A missed heartbeat alert no longer says "Overdue 0s". It now says when the last check-in arrived and when the next one was expected, in UTC in Telegram and email, and in your local time in Slack. Webhooks gain detail.deadline_at (unix seconds) with the same expected-by time; the existing fields are unchanged.

When a monitor was only slow, for example a job that ran longer than its max run time, and then recovers, the alert now says it's back to normal, with how long it was slow when that is known, instead of announcing a "back up" after an outage that never happened. Other degraded states, such as an expiring certificate, read "Degraded for" rather than "Slow for". A monitor that did go down still says how long it was down. Webhook recoveries add detail.down_seconds and detail.degraded_seconds, and a recovery from a slow-only episode uses the reason "Back to normal".

Safer heartbeat settings in the API and the app

A few heartbeat details are now stricter, so a typo can no longer quietly switch off a monitor.

• Limits on grace period and interval. A heartbeat's grace period must be a whole number of seconds from 1 to 2,592,000 (30 days), and no monitor's check interval can be longer than 365 days. An extreme value used to be saved without complaint, and the monitor could then stop alerting or flap. The app now shows the problem next to the field, and the API answers with an error.
• Read-only API tokens no longer see heartbeat ping URLs. The ping URL works like a password, so only tokens with write access get it when they fetch a heartbeat monitor. The app and Terraform are not affected.
• The API refuses a setting that never worked. Setting failEnabled to false on a heartbeat is now an error. A failure check-in always marks the monitor down, and that can't be turned off.
• Clearer errors for check-ins. If something goes wrong on our side while recording a check-in, your job now gets a temporary error it can retry, instead of the same answer as for a wrong URL.

A heartbeat run that passes its time limit is flagged while it's still running

If you set "Alert if a run takes longer than" on a heartbeat and your job sends /start, a run that is still going when the limit passes now marks the monitor degraded and alerts you at that moment. Before, a run that never finished was only reported later, at the normal check-in deadline, as a missed check-in.

The alert says what we saw, for example "Run started 14:03 UTC, no finish check-in within 1h". When the run's finishing check-in arrives, even late, the monitor recovers. If the job reports a failure, it goes down as usual, and if nothing arrives by the normal deadline, it goes down as a missed check-in.

Changing a heartbeat's schedule no longer sends a false alert

Changing the interval or grace period of a running heartbeat could mark a healthy job down and alert you, because the old deadline was still being counted. Now the next check-in is due one full new interval plus grace period after you save, and a shorter schedule takes effect right away instead of waiting for the old, longer deadline.

When a heartbeat misses its check-in, "Last beat" now shows when your job really last checked in, not the moment it was marked down, and the monitors list marks the missed run instead of staying green.

Heartbeat setup now matches your schedule

A new heartbeat monitor now opens on its check-in URL and snippet, right after you create it, instead of an empty Incidents page. It also says plainly that CuliPulse isn't watching yet: a heartbeat starts being watched at your job's first check-in, so run the job once (or the new "test the connection" command) and wait for "First check-in received".

The crontab and Kubernetes snippets used to always say "every hour". They now carry the schedule that matches the interval you chose (every 5 minutes, every day at 03:00, and so on). Where cron can't run that often, or can't express the interval exactly, the snippet says so.

If you set a run-time limit ("Alert if a run takes longer than"), the snippets now include the /start line it needs, and the wording everywhere says what is measured: from the /start request to the finishing check-in. A heartbeat you create in the app now starts with a grace period of 20% of its interval when that is more than 10 minutes (5 hours for a daily job), which also covers the hour lost or gained when the clocks change. There's a new Heartbeat monitors page in the docs.

Heartbeats you already have keep their grace period. To get the schedule-aware snippet, copy it again from your monitor's page.

A failed check no longer says "nothing to worry about"

When a website monitor is Down because the server answered with an error (a 503, a 404, a 401), the Latency tab used to show "All phases were fast, nothing to worry about" right under the red Down banner. It now says what happened instead, for example "This check failed: the server answered HTTP 503 (service unavailable)", and no longer comments on speed for that check. The same goes for the result of "Diagnose now". If this location's check passed while other locations are failing, it says so instead of reassuring you. Checks that pass keep the speed summary.

Safer notification destinations

You can no longer save a "Specific monitors" destination with no monitors picked. Before, it showed as connected but never sent anything. Pick at least one monitor, or choose All monitors. If you manage destinations with Terraform or the API, nothing changes: routing a destination to no monitors there still works and mutes it on purpose.

Routing a destination to 100 or more monitors now works. Before, the save failed with an error and had already removed the destination's existing routes. A routing change is now saved as one step, so a refused or failed save leaves your current routing as it was. A list longer than your plan's monitor limit (or than the monitors you own, if that is more) is refused with a clear message.

An account can now have up to 20 notification destinations (email counts as one). If you already have more, you keep them; you just can't add new ones until you're under the limit. Adding a second webhook for exactly the same URL is refused too, and a refused destination never gets a test request. Test alerts are spaced about 30 seconds apart per destination, and CuliPulse says how long to wait.

Notifications now tell you when alerts can't reach you

The Notifications page used to show a green Connected for a destination that was switched off, still waiting to connect, had bounced, or had quietly stopped working. Now each destination says what it is really doing, and the header counts only the ones that can receive an alert, for example "2 receiving · 1 need attention".

• If an alert couldn't be delivered, the row turns amber and says what happened, for example "A delivery failed 4 min ago: Telegram says the bot was blocked or removed from this chat". A successful test alert or delivery clears it.
• A destination that is off, has an expired link, or is set to specific monitors with none selected says so instead of Connected. The Alerts routed step on the Getting started list now ticks only for a destination that is on and covers at least one monitor.
• You can no longer save a destination set to specific monitors with none selected. If you delete the last monitor it covered, it shows Specific, 0 monitors and Not receiving.
• A monitor's page and the create and edit forms now show Alerts go to: with the destinations that will alert for it, and warn when nothing will. A destination set to specific monitors does not pick up monitors you add later, and the page now says so.
• A Telegram link now shows when it expires and, once it has, tells you and offers Get a new link instead of waiting forever. Coming back from Slack after cancelling or a failed approval now shows a clear message with a way to try again.
• "Send test alert" now says where the test landed and how long to wait if you press it twice, instead of "check Webhook".

There is also a new docs page, "Not getting alerts?", that walks through every status and what to do about it.

Test alerts are now clearly marked as tests

When you press Send test alert (or add a webhook), the message you get now says it is a test. The title starts with TEST, and a line underneath reads "This is a test, nothing is down". Before, a Telegram or Slack test looked exactly like a real outage for a monitor called "checkout-api" or "Example API", which was alarming in a team channel. Email tests now show a grey TEST label instead of the red DOWN one.

Webhook tests carry "test": true in the JSON body, so your receiver can tell them apart from real alerts. Real alerts are unchanged and never have that field.

If you press Start on a Telegram connect link that has expired, the bot now tells you the link expired and to press Connect again in CuliPulse, instead of staying silent. It answers at most once an hour per chat.

There are also new Telegram and Slack pages in the docs. They cover how to connect, what to do when a link expires or the Slack approval doesn't finish, and what happens if you block the bot or remove the app.

The console now shows a page-text check set through the API or Terraform

If an HTTP monitor has a "page must contain" text set through the API or Terraform, you can now see it in the console. It appears on the monitor's Settings tab and under Advanced when you edit the monitor. It is read-only there, and saving in the console keeps it.

• Before this, a monitor could go down with "Page missing expected text" for a check the console never showed
• To change or clear the text, use the API or Terraform
• Fixed the agent list in the monitor form repeating the location name on every shared agent
• Fixed a very long address making the monitor form scroll sideways on a phone

Port and UDP alerts now say what went wrong

A port (TCP) or UDP monitor alert now tells a server that is down apart from a check that needs adjusting.

• "Couldn't connect" means nothing answered on that port. "Connected, but the reply didn't match" names the text the monitor expected, so a wrong expected text no longer looks like an outage
• A UDP monitor that gets no answer now says "No reply to our test message" and reminds you the server may expect a different payload. Many UDP servers (games, VoIP) ignore an empty message, and the monitor form now warns about that
• A private name such as db.internal can't be reached from our shared locations. The alert and the monitor form now point you to running your own agent instead of only saying "Domain not found"
• A mail greeting that arrives in several pieces (like a multi-line SMTP greeting) is now read until it matches, the server closes the connection, the server goes quiet for 3 seconds, or the check times out, instead of being judged on the first piece. A server that pauses longer between lines is still judged on what had arrived. This part reaches checks as each agent is updated
• Webhook payloads keep the same fields. Only the wording of reason changes, so if you match on that text, check your rules

No more false "Back up" alert on a heartbeat's first check-in

A heartbeat monitor used to send a "Back up" alert the first time your job checked in, and again on the first check-in after you resumed a paused heartbeat, even though nothing had gone down. Those alerts are gone: the monitor just turns up quietly. You are still alerted when a heartbeat goes down, runs too long, and when it recovers from either.

Incidents say which status code you expected

If a website monitor expects a specific status (say 3xx) and the site answers with something else, the incident and the alert now read "HTTP 200 — expected 3xx" instead of just "HTTP 200". The checkpoint reasons on the monitor page say the same. A default monitor that gets a redirect reads "HTTP 301 — expected 2xx". Ordinary error replies such as "HTTP 503 (service unavailable)" read as before.

Incidents close when a monitor can't be checked

If you delete the only agent checking a monitor, or it stays offline until the monitor turns unknown, an open incident now closes instead of staying red and counting downtime that nobody measured. If the target is still failing when checking resumes, a new incident opens and you get a fresh down alert; if it's fine, nothing is sent.

A monitor that is down also always shows its open incident now. In rare cases a down monitor could have no incident at all, so its uptime read 100%; it now gets its incident back, dated from when it went down, without sending a new alert.

Latency numbers only count checks that got a reply

A failed check no longer counts as a response time. Before, a monitor that timed out showed its timeout as "latency": a down port could read "Avg latency 10001ms", and one timeout in an otherwise fast monitor pushed the p95 up to the timeout.

Average latency, p95, the latency column in the monitor list and the Overview average now use successful checks only. A failed check shows as a gap in the latency chart, and a monitor whose latest check failed shows "—" for latency.

Down alerts no longer say the monitor "responded in 10s" when nothing answered. The response time is left out of the Telegram, Slack and email alert, and detail.latency_ms is omitted from the webhook, when the check timed out or the port was refused or silent. A page that answers with an error (such as HTTP 503) still shows how long it took.

Port and UDP checks can now send line breaks, and the Redis check keeps its line break when you edit it

The payload field on TCP port and UDP checks says to type PING\r\n for Redis, but that used to send those characters literally, so the service never answered and a healthy server showed as down. Now \r, \n and \t are sent as a carriage return, a line feed and a tab, \xHH sends the character with that code (up to \x7F), and \\ sends one backslash. For raw bytes, switch the encoding to hex.

The ready-made Redis check also lost its line break the moment you opened it for editing and pressed a key in the payload field. It now shows the payload as PING\r\n and keeps it, and the monitor page shows the same text instead of a stray space.

If you send payloads through the API, the same rules apply there. A payload that contains a backslash followed by r, n, t or x now means the character, not the two letters; write \\ to send a real backslash.

Port checks catch a pasted web address, and the DNS resolver check no longer calls a failing resolver up

Pasting https://example.com:443 (or a path, or a name with a space) into a TCP port or UDP check used to be accepted, then show as down a minute later with no explanation. It is now turned down when you save, with a message that says what to change. IPv6 addresses go in square brackets, like [2001:db8::1]:53. Shared locations also refuse a target that points at the machine itself, since they cannot reach it; check those from your own agent.

The ready-made DNS resolver check now counts only a normal answer as up. A server that answers with "refused" or "server failure" used to show as up even though it was not resolving anything; it now shows as down.

The "View incident" link brings you back to the incident after you sign in

Opening an alert's "View incident" link while signed out used to drop you on your monitors list after you signed in. Now you land on the incident you came for, whichever page the link pointed to. If your phone opens the sign-in in a different browser than the one holding the link, you'll still land on your monitors list.

Upgrade to Solo or Pro by card

You can now upgrade your plan yourself, any time, without emailing us.

• Pay by card. On the Plans page, click Upgrade and pay on a secure checkout page. Your new limits apply as soon as the payment goes through.
• Manage it yourself. From Billing → Manage billing you can switch plans, update your card, download invoices or cancel.
• Cancelling keeps what you paid for. You stay on your plan until the end of the period you've paid for, then move to Free.
• Your monitors are never switched off over billing. If a payment fails, everything keeps running and you get 14 days to sort it out.

Payments are handled by Polar, our payment provider, which also takes care of sales tax and VAT and sends your invoices.

Recovery alerts name the latest failure

When a monitor's failure changes during an outage (say from HTTP 503 to HTTP 502), the open incident now shows the latest failure, and the "recovered" alert names the last failure seen before the monitor came back. Before, both kept the first failure of the outage.

Shared reports no longer show login details in monitor addresses

The public link of an uptime report now shows each monitor's address without any login details, query string or # part. If you put a password or an API key in a monitor's URL, it is no longer visible to the people you share the report with. You still see the full address in the app.

body_match on API and Terraform HTTP monitors is now checked

If you set body_match on an HTTP monitor through the API or Terraform, CuliPulse now checks that the response contains that text, and marks the monitor down with "Page missing expected text" when it doesn't.

• Before this fix, the text was saved but never checked
• The text is case-sensitive and can be up to 1,024 characters
• In the console, use a "Body contains" assertion for the same check

Secret headers added in the console are now saved

Secret headers you add to a Website / HTTP check in the console are now saved.

Before this fix, a secret header typed in while creating a check — or added to a check that had none yet — was quietly left out, so the check ran without it. If you set one up that way, open the check, add the secret header again and save. Secret headers set through the API or Terraform were not affected.

Alerts now tell you when a domain doesn't resolve

When a website, TCP, UDP or ping monitor can't find its domain (an expired or mistyped domain, or a deleted DNS record), the alert and the monitor page now say "Domain not found". A DNS lookup that fails or times out reads "Couldn't look up the domain".

• Before, a website check said "Connection failed", which pointed you at your host instead of your domain or DNS, and a slow DNS lookup looked like the site or port timing out
• This comes from the checking agent, so it shows up as each agent is updated: our shared locations first, then agents you run yourself once you update them
• API users will see the cause values dns_nxdomain and dns_error on these monitors' incidents

Pasting a health URL no longer adds a hidden reply check

When you paste a health URL such as https://api.example.com/health on the New monitor screen, the new check now just expects the endpoint to answer with a success status.

Before, it also quietly required the reply to contain the exact word "ok", so an endpoint that answers UP, OK or healthy showed as down from its first check. If you want the reply text checked, tick Also check the reply says it's healthy and type the word your endpoint sends. Checks you already created this way keep their reply check; if yours doesn't answer with "ok", open the check and remove the response check under Advanced.

Monitor pages now say why a check failed

When a check fails, the Checkpoints tab on the monitor page now tells you why in plain words, such as "Connection failed (refused / unreachable)" or "HTTP 503 (service unavailable)", the same wording as your alerts.

Before, a failed checkpoint often just said "unavailable", which read as if our checker was broken rather than your site, and Port, Ping and UDP monitors showed it for every failure. Checkpoint unavailable now only appears when a checkpoint really couldn't run the check.

Diagnose now also reports a failed check and its reason. Before, a failed diagnosis showed nothing, or only its timings without saying the check failed.

Saving a monitor now tells you why it was refused

When the console can't save a monitor because of something in the request, it now tells you the reason instead of a generic "something went wrong on our side".

• Going over a size limit names the limit, such as a header value that's too long
• Reaching a plan limit says which one, such as the number of monitors on shared locations or your monthly check budget
• A genuine problem on our side still says so, with a request id you can send to support

The monitors list no longer calls unchecked monitors healthy

On the Monitors page, a monitor we couldn't get a reading for (Unknown) now appears under Needs attention, and a brand-new monitor that hasn't finished its first check appears under a new Waiting for first result group.

Before, both were listed under Healthy, which could hide a monitor nobody was actually watching. Healthy now only lists monitors whose last check passed.

A paused monitor now always shows as Paused. Before, a monitor paused while its last check had no reading could show as Unknown on the monitor page and the overview, or as No data on your public status page.

More status pages and longer history on paid plans

Paid plans now get more status pages and a much longer history.

• More status pages. Solo includes up to 3 status pages and Pro up to 10, for example one per product or per customer. Free keeps 1. Create, edit and delete them from the Status pages list in the console.
• Longer history. Solo now keeps 1 year of history and Pro 2 years. Free keeps 30 days of history.
• Pick the range you want. A monitor's page has a range picker (30 days, 90 days, 1 year, 2 years), and the ranges your plan doesn't include show as locked.
• Longer reports. Build an uptime report for the last 12 months on Solo, or the last 24 months on Pro — a shortcut fills in the dates for you.

Your existing history is all still there. If you upgrade, the longer range shows up straight away.

Every HTTP method in the console

Website / HTTP checks in the console now offer every method the API supports.

• Pick GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS when you create or edit a check
• Send a request body with PUT, PATCH, DELETE and OPTIONS, not just POST
• Editing a check made through the API or Terraform keeps its method and request body

Email alerts for existing accounts

Accounts that had no alert destination turned on now get email alerts too.

• Alerts go to the account owner's sign-in email and cover all your monitors
• Already using Telegram, Slack or a webhook? Nothing changes unless you want it: add email yourself under Notifications → Add destination → Email
• Don't want them? One click at the bottom of any alert email turns them off, or switch email off under Notifications

Size limits for monitor settings

Monitors now have clear size limits, so one oversized monitor can never slow down monitoring for anyone else.

• A monitor's target (the URL or host it checks) can be up to 2,048 characters
• Each HTTP request header value can be up to 8,192 characters, and the whole check configuration up to 128 KB
• No existing monitor comes close to these limits, so nothing changes for you
• Saving a monitor over a limit is refused; through the API or Terraform, the error names the limit that was hit

Secrets stay with the site you're checking, even through redirects

When a website check follows a redirect, its secret headers, sign-in details and secret request body now go only to the site you set up, or one of its subdomains.

• A redirect to a different site still gets checked, just without your secrets
• A check that carries secrets won't follow a redirect from https:// to plain http://. It shows "Redirected to an unencrypted http:// address" so you can point it at the secure URL
• Checks without secrets follow redirects exactly as before

Email alerts

New accounts now get email alerts from the moment they sign up.

• Alerts go to the email address you sign in with and cover all your monitors
• Each email says what we saw, where and when, with a button straight to the incident
• One click at the bottom of any alert turns email off; switch it back on under Notifications
• At most 20 emails an hour, so a flapping monitor can't flood your inbox

New shared checkpoint in Montreal

CuliPulse now checks from a third shared location: Montreal, Canada, alongside Singapore and Frankfurt.

• Pick North America (Montreal) as a checkpoint when you create or edit a Website, Port, Ping, or UDP monitor. No setup needed, and it's available on every plan
• Useful for sites and APIs whose users are in North America. You now see the latency and reachability they see
• On Solo and Pro, checking from more than one location also helps avoid false alarms from a blip on a single network path (Free monitors check from one location)
• Our privacy policy now lists Canada among the places where our checking servers run

Public status pages

You can now publish a public status page for your users at culipulse.dev/s/your-name, included on every plan.

• Pick up to 50 monitors and give each one a name your users will recognise
• Visitors see what's working right now, anything happening now, and the last 90 days day by day
• Your URLs, server addresses, error details and settings are never shown
• Turn the page off at any time from Status page in the console

Discovered monitors now follow your plan's check interval

Monitors created from cloud discovery or a local network scan used to check every minute on every plan. They now check at your plan's fastest interval, or every minute if your plan allows faster, so on Free they check every 5 minutes, the same as monitors you create yourself.

Large AWS accounts are now discovered in full

AWS discovery now reads every page of load balancers, servers and databases, so accounts with many resources are no longer cut off after the first batch. If AWS refuses or times out while reading part of a scan, the error now shows on the agent's page, and the affected resources keep their last known details instead of losing their ports or tags. Update your agent to version 1.11.0 to get this.

Vendor monitors now explain when watched components are removed

If you've narrowed a vendor status monitor to watch specific components, and all of those components get removed from the vendor's status page (for example the product is discontinued), the monitor now shows unknown with a clear notice about what happened.

• The monitor shows you that your watched components are no longer on the vendor's status page and asks you to re-select components in Edit
• Once you pick new components, the monitor recovers on the next check (usually within a minute)
• Before this fix, monitors in this situation wrongly claimed the status page was unreachable

Cloud discovery: monitors you adopt stay healthy

A monitor you adopt from a discovered AWS resource is now flagged "orphaned" when its resource disappears from scans, or when CuliPulse can no longer tell how to check it. Before, a monitor adopted in one click without a matching rule was flagged on the very next scan, even though its resource was still there. Editing or removing your match rules no longer flags monitors you already adopted.

An HTTP monitor created from a discovered resource, such as a load balancer, now checks a full web address that starts with http:// or https://, depending on the port. Before, it was given the bare host name and could never connect, so it stayed down even when your site was up.

A discovery scan that runs into an error, for example after the agent's AWS permissions change, no longer marks your resources as gone or flags their monitors. The agent's page shows the error. Once you fix it, the next scan without errors brings everything up to date.

Clearer monitor history, easier vendor and template setup

The 90-day history bar on a monitor's page now tells degraded from down apart: a day that was only slow, or briefly close to a limit, shows amber. Red is reserved for a day the monitor was actually down. Your uptime percentage was never affected by degraded time — this only changes how the bar reads.

Creating a vendor-status monitor now fills in its name for you, using the vendor you picked.

The monitor template picker no longer suggests that some checks need an agent of your own to set up. Checks on public hosts can run right away from CuliPulse's shared locations (Singapore and Frankfurt) — use your own agent for anything private.

Pause and resume monitors from the API

You can now pause and resume a monitor from the API, not just from the app: send a POST to /v1/monitors/{id}/pause or /v1/monitors/{id}/resume with a Read + Write token. Both are safe to repeat — pausing a paused monitor, or resuming one that's already running, changes nothing.

Editing a monitor through the API now tells you when you send a field that can't be changed that way. Before, a request that included something like enabled or status was accepted but did nothing, so a monitor you meant to pause kept checking and alerting. Now that request is refused with a clear message: the error names the field and says what to do instead.

Editing a paused monitor, including with Terraform, keeps it paused.

Pausing a monitor mid-outage no longer erases the outage

Pausing a monitor while it was down or degraded used to close out that outage without counting the part of it still in progress — so uptime and reports understated how much downtime actually happened. Now, pausing folds that time in first: downtime up to the moment you paused is counted, and only time after you pause is excluded.

Heartbeat snippets no longer report a false failure

The ready-to-copy heartbeat snippets now send your job's exit code in a single check-in: 0 means the run worked, anything else marks the monitor down right away.

Before, if a job succeeded but its check-in was lost on the way (for example a brief network blip), the snippet fell back to reporting a failure and the monitor went down for a job that had worked. Now a lost check-in is never reported as a failed job — if nothing arrives before the grace period ends, you get the normal missed-check-in alert instead.

If you copied a snippet before, copy the new one from your monitor's page. The old one keeps working; it just can't tell a failed job from a lost check-in.

New monitors show their first result right away

Domain, DNS and third-party status monitors, and monitors checked from checkpoints, used to show "Pending" for up to an hour after you created or resumed them. They now pick up their first check result as soon as it's ready, usually within a minute.

Domain monitors now also show which registrar the domain is registered with.

Shared locations never reach into private networks

Checks from CuliPulse's shared locations now refuse to connect to private or internal addresses at every step — including when a site redirects somewhere internal, or a domain's address changes later. If that happens, the monitor tells you plainly why.

To watch internal hosts, run your own agent.

Updated Terms of Service and Privacy Policy

We updated our Terms of Service and Privacy Policy to cover what CuliPulse does today: Slack and webhook alerts, the API, and paid plans. The privacy policy now lists every service that handles your data, and says plainly how long monitoring history is kept. The security page also explains how webhooks are signed and how tokens are stored.

Monitor pages no longer show old or made-up readings as current

Two places on a monitor's page could look healthier than they really were:

• When a vendor's status page can't be read, the page no longer shows the last reading (for example "All Systems Operational") as if it were current. It says Unknown and shows the old reading as last known, with how long ago it was read
• A new monitor with no results yet no longer shows 100% uptime and a green bar for today. It shows no figure until the first check comes in
• The "can't check right now" notice now appears at the top of the page, above the status

No more false "recovered" alerts when a vendor's status page can't be read

If a vendor's status page couldn't be loaded, a monitor watching the whole vendor counted that as all-clear. A monitor that was down or degraded could then send a false "recovered" alert, then alert again on the next check.

• An unreadable status page now keeps the monitor in its current state, and CuliPulse tries again a minute later
• If the page stays unreadable for three checks in a row, the monitor shows as unknown, the same as monitors that watch specific components
• A brand-new vendor monitor now says it's waiting for its first reading instead of calling the status page unreachable

A heartbeat's max run duration is now saved when you create it

If you set a Max run duration while creating a heartbeat monitor, it wasn't saved, so a run that took too long never marked the monitor degraded. It's saved now, and Terraform updates no longer clear a max run duration you set in the app.

• Created a heartbeat with a max run duration before today? Open the monitor, choose Edit, and set it again
• Values set later through Edit were saved correctly and need no action

Manage monitors as code with Terraform and OpenTofu

The official CuliPulse provider is now on the Terraform and OpenTofu registries as culipulse/culipulse. Keep your monitors, webhooks and alert routing in code, review changes in a pull request, and apply them in one step.

• HTTP and heartbeat monitors, webhook channels, and alert routing for any channel
• Bring existing monitors under Terraform with terraform import
• Works with Terraform 1.5+ and OpenTofu 1.6+ and a Read + Write API token — see the guide

Vendor status monitors alert again

Since September 2, some vendor status monitors didn't alert at all — not for posted incidents, outages, or degraded components. The problem was on our side. We've fixed it and they alert again. We're sorry for the missed alerts.

• Vendor status is now checked every interval as intended. Before, some checks were skipped and the monitor briefly showed as "unknown"
• If you watch a whole vendor, an incident the vendor posts now marks it degraded. Down is kept for when the vendor's status page shows its overall status as a major or critical outage. Watch specific components if you want a full outage alert for just the parts you use

Monitors now restart themselves if they ever stop checking

Between September 12 and September 23, many monitors quietly stopped running their checks after a platform hiccup, and stayed stopped until they were paused and resumed. They didn't alert during that time. We've fixed the cause, restarted the affected monitors, and added a safety net: a monitor that stops checking for any reason is now restarted automatically. We're sorry for the gap in coverage.

• No action needed on your side: affected monitors are already checking again
• Your uptime history for that window may show fewer checks than usual

All the answers in one place at docs.culipulse.dev

The new CuliPulse docs cover everything from your first monitor to webhooks and the API.

• Step-by-step guides for monitors, alerts, checkpoints and agents, notifications, reports and plans
• An API reference that always matches what the API actually accepts
• Search across every page

Use CuliPulse from your own scripts with the API

CuliPulse now has a public REST API at https://culipulse.dev/v1, so you can read and manage your setup from scripts, CI pipelines or your own tools.

• Create a token under Settings → API Tokens, either read-only or read + write. It's shown once, and you can revoke it any time
• Read monitors, incidents, reports, notification channels and agents; create, update and delete monitors and channels
• Each token gets 60 requests per minute on Free and 600 on Solo and Pro
• The full reference, generated from the live API, is at docs.culipulse.dev

Send alerts to your own webhook

Add a Webhook destination and CuliPulse will POST a signed JSON payload to your own endpoint the moment a monitor changes state — so you can route alerts into PagerDuty, Opsgenie, Zapier, n8n, or anything you build yourself.

• Point it at any HTTPS endpoint — we send one test delivery before it goes live, so you never ship a dead webhook
• Every request is signed with a secret you copy once at setup, so your receiver can verify the alert really came from CuliPulse
• Send everything, or scope a webhook to specific monitors

A simpler way to create a monitor

Creating a monitor now starts with just the essentials: a name, what to check, and how often. Everything else sits in collapsed sections with sensible defaults, so you can add a monitor in seconds and fine-tune it later.

• Alerts, advanced and extra options are grouped, and each one tells you what it's currently set to
• If something needs fixing, the form takes you to the exact field and explains the problem in plain language
• Works the same way for every check type

Send alerts to a Slack channel

Connect a Slack workspace and CuliPulse will post alerts straight into the channel your team already watches — click "Add to Slack", approve it, and pick a channel. No bots to configure.

• Add it from Notifications, then choose which channel alerts land in
• Alerts arrive as clean, readable Slack messages showing what changed and the monitor's current status
• Send everything, or scope a Slack destination to specific monitors

Tune when a service counts as recovered

You can now set how many good checks in a row it takes before CuliPulse calls a service recovered, and how many failing checkpoints it takes to call it down. Fewer false alarms when a flaky service bounces up and down.

• Set a recovery threshold per monitor
• Require agreement from more than one checkpoint before you get paged

Filter your monitors by who runs them

Filter the monitors list by All, Shared, or Private, so you can quickly separate the checks CuliPulse runs for you from the ones your own agent runs behind your firewall.