Introducing ping and TCP port monitoring (and lots of other improvements) Published on August 26, 2025 by Freek Van der Herten @freekmurze Freek Van der Herten August 26, 2025 A couple months ago, we sent out a survey to all our users asking what they like about Oh Dear, how they use it, and how we could improve our service. One of the things that was asked a lot was ping and TCP port monitoring. The past few months we worked hard to add this kind of monitoring to our service. And while building it, we touched upon other parts of our service and improved lots of little things. And I'm proud to share that we now have shipped it all! Let's go through it! Goodbye sites, welcome monitors Let's take a look at the dashboard at Oh Dear. Long time Oh Dear users will probably notice that "sites" isn't in the main navigation anymore. It has been replaced by "monitors". Since Oh Dear started, we always had the concept of a "Site" you're monitoring. But with the introduction of Ping and TCP checks, we can now monitor more than just a site. That's why we renamed the "Site" concept in Oh Dear to "Monitor". Not only the main navigation has changed, but we updated all copy throughout our entire app and docs. A monitor will have a type: HTTP: for checking websites Ping: for checking servers via ICMP ping TCP: for checking the connectivity of a port over TCP When you now create a monitor in Oh Dear, this new dialog pops up, which lets you choose the type of monitor. Monitor your servers via ping Let's explore the new ping monitoring type. With HTTP monitoring we're sending an HTTP request to your app to see if it works. With ping monitoring, we're sending an ICMP(v6) ping packet to your server, so this kind of monitoring is more low-level. Ping checks if your server is responding at the most basic network level. If ping fails, you know there's a fundamental connectivity issue before users even try to access your site. Adding a ping monitor is easy, just select the ping type, enter the address (either a FQDN hostname or the IPv4 or IPv6 address) of your server and you're good to go. On the uptime report of a ping check, you can see the average response time, together with the raw ping output. When you scroll down a bit, you'll see a full graph of how the ping check performed over time. Needless to say, whenever the ping fails, we'll send you notifications, via one of our many available notification channels. The ping check can also be customized to your heart's content. You can choose how many packets should be sent, what their size should be, define the acceptable packet loss, and much more. Monitor TCP ports Let's take a look at the second new monitoring type: TCP ports. TCP port monitoring checks if specific services are running and accepting connections on their designated ports, giving you more targeted insight than basic ping monitoring: While ping only tells you the server is reachable, TCP port monitoring verifies that specific services (web server on port 80/443, database on 3306, SSH on 22, etc.) are actually listening and responding. When creating a monitor, you can now choose the TCP type. For this example we're going to monitor smtp.google.com:587, Gmail's mail server. Let's maybe look at the settings of a TCP monitor first. On the image above you see that we can check the welcome message the server will send back. If the welcome message doesn't contain the string given, we'll regard the server as down. Optionally, you can also send a message to the server, and also check if the response we get for the message contains a substring. This way you can really test particular behavior of your server. On the TCP result page, we'll show the welcome message (and also the response of the optional message when it has been set) Our API has been updated as well Across our UI, notifications and docs, we have changed the language so we'll talk about "Monitors", instead of "Sites". We've also updated our entire codebase. Internally our Site model is renamed to Monitor, together with all relationships, foreign keys, views, controllers... Together with the technical rename, we'll also pay off other technical debt that was accrued over the years. This has also affected our API. At Oh Dear, we value backwards compatibility. In the eight years that we've been in operation, we've never made a breaking change to our API. We also considered keeping a v1 of our API, but we decided against it because the maintenance burden would be too big. On this FAQ page, you can read more info on which exact breaking changes we've made, and how you can upgrade. A new homepage To promote ping and TCP monitoring, we added two dedicated new pages, one for ping, and one for TCP. These pages both have beautiful illustrations, made by our designer Nick. We also took the time to update our homepage to mention the new feature, and also to show some nice screenshots from our app. The features and docs menu were revamped as well. Bonus feature: customize the frequency of the checks We've also shipped another small, but often requested feature: you can now choose the frequency of the check we run. By default, we check your website for uptime every minute. The Lighthouse check runs daily. Using our new feature, you can now for instance choose that the uptime check should run every 2 minutes, and the Lighthouse check every 5 days. You can choose the frequency at the settings of the check. In closing We hope you'll like these updates we've made to Oh Dear. We aren't done and are building more exciting features, but it's a bit too early to talk about those. Should you have any suggestions on how to improve Oh Dear, do let us know by filling in our survey or just emailing support. We'll close off this post by highlighting some of the features that were requested through our survey: We now log sent notifications Our new SDK has been rebuilt from the ground up People with a big number of sites in their team reported that the site list screen is slow. We made it faster, and are still optimizing it. There's a new usage screen that shows your usage against your current plan Maintenance periods can now have a name We can now send notifications via Google Chat The certificate health check has a new "Detected Certificates" tab showing the history of certificates we detected for a site. A graph was added to the Lighthouse result history Our blog layout was simplified. We made it more clear across our UI which things are clickable, by adding the cursor-pointer CSS class to those elements You can now manage monthly reports with our API Alert snoozing now has full history A new login method was added: passkeys Our broken links check has a new "Troubleshooting" tab, showing you tips to fix broken links. We merged our uptime and performance check
A couple months ago, we sent out a survey to all our users asking what they like about Oh Dear, how they use it, and how we could improve our service. One of the things that was asked a lot was ping and TCP port monitoring. The past few months we worked hard to add this kind of monitoring to our service. And while building it, we touched upon other parts of our service and improved lots of little things. And I'm proud to share that we now have shipped it all! Let's go through it! Goodbye sites, welcome monitors Let's take a look at the dashboard at Oh Dear. Long time Oh Dear users will probably notice that "sites" isn't in the main navigation anymore. It has been replaced by "monitors". Since Oh Dear started, we always had the concept of a "Site" you're monitoring. But with the introduction of Ping and TCP checks, we can now monitor more than just a site. That's why we renamed the "Site" concept in Oh Dear to "Monitor". Not only the main navigation has changed, but we updated all copy throughout our entire app and docs. A monitor will have a type: HTTP: for checking websites Ping: for checking servers via ICMP ping TCP: for checking the connectivity of a port over TCP When you now create a monitor in Oh Dear, this new dialog pops up, which lets you choose the type of monitor. Monitor your servers via ping Let's explore the new ping monitoring type. With HTTP monitoring we're sending an HTTP request to your app to see if it works. With ping monitoring, we're sending an ICMP(v6) ping packet to your server, so this kind of monitoring is more low-level. Ping checks if your server is responding at the most basic network level. If ping fails, you know there's a fundamental connectivity issue before users even try to access your site. Adding a ping monitor is easy, just select the ping type, enter the address (either a FQDN hostname or the IPv4 or IPv6 address) of your server and you're good to go. On the uptime report of a ping check, you can see the average response time, together with the raw ping output. When you scroll down a bit, you'll see a full graph of how the ping check performed over time. Needless to say, whenever the ping fails, we'll send you notifications, via one of our many available notification channels. The ping check can also be customized to your heart's content. You can choose how many packets should be sent, what their size should be, define the acceptable packet loss, and much more. Monitor TCP ports Let's take a look at the second new monitoring type: TCP ports. TCP port monitoring checks if specific services are running and accepting connections on their designated ports, giving you more targeted insight than basic ping monitoring: While ping only tells you the server is reachable, TCP port monitoring verifies that specific services (web server on port 80/443, database on 3306, SSH on 22, etc.) are actually listening and responding. When creating a monitor, you can now choose the TCP type. For this example we're going to monitor smtp.google.com:587, Gmail's mail server. Let's maybe look at the settings of a TCP monitor first. On the image above you see that we can check the welcome message the server will send back. If the welcome message doesn't contain the string given, we'll regard the server as down. Optionally, you can also send a message to the server, and also check if the response we get for the message contains a substring. This way you can really test particular behavior of your server. On the TCP result page, we'll show the welcome message (and also the response of the optional message when it has been set) Our API has been updated as well Across our UI, notifications and docs, we have changed the language so we'll talk about "Monitors", instead of "Sites". We've also updated our entire codebase. Internally our Site model is renamed to Monitor, together with all relationships, foreign keys, views, controllers... Together with the technical rename, we'll also pay off other technical debt that was accrued over the years. This has also affected our API. At Oh Dear, we value backwards compatibility. In the eight years that we've been in operation, we've never made a breaking change to our API. We also considered keeping a v1 of our API, but we decided against it because the maintenance burden would be too big. On this FAQ page, you can read more info on which exact breaking changes we've made, and how you can upgrade. A new homepage To promote ping and TCP monitoring, we added two dedicated new pages, one for ping, and one for TCP. These pages both have beautiful illustrations, made by our designer Nick. We also took the time to update our homepage to mention the new feature, and also to show some nice screenshots from our app. The features and docs menu were revamped as well. Bonus feature: customize the frequency of the checks We've also shipped another small, but often requested feature: you can now choose the frequency of the check we run. By default, we check your website for uptime every minute. The Lighthouse check runs daily. Using our new feature, you can now for instance choose that the uptime check should run every 2 minutes, and the Lighthouse check every 5 days. You can choose the frequency at the settings of the check. In closing We hope you'll like these updates we've made to Oh Dear. We aren't done and are building more exciting features, but it's a bit too early to talk about those. Should you have any suggestions on how to improve Oh Dear, do let us know by filling in our survey or just emailing support. We'll close off this post by highlighting some of the features that were requested through our survey: We now log sent notifications Our new SDK has been rebuilt from the ground up People with a big number of sites in their team reported that the site list screen is slow. We made it faster, and are still optimizing it. There's a new usage screen that shows your usage against your current plan Maintenance periods can now have a name We can now send notifications via Google Chat The certificate health check has a new "Detected Certificates" tab showing the history of certificates we detected for a site. A graph was added to the Lighthouse result history Our blog layout was simplified. We made it more clear across our UI which things are clickable, by adding the cursor-pointer CSS class to those elements You can now manage monthly reports with our API Alert snoozing now has full history A new login method was added: passkeys Our broken links check has a new "Troubleshooting" tab, showing you tips to fix broken links. We merged our uptime and performance check