Before you start
You need a monitoring account and a URL to monitor. That is it. No code to deploy. No agent to install. No configuration files to edit.
If you do not have an account yet, PingWatchdog’s Free plan gives you 15 monitors, 5-minute checks, SSL monitoring, heartbeat monitoring, and a branded status page. No credit card required.
Step 1: Add your first monitor
Go to your dashboard and click “Add monitor.” You will see a form with a few fields.
URL: Enter the full URL you want to monitor. Use the exact endpoint your users hit. For a website, that is https://yoursite.com. For an API, use the specific endpoint like https://api.yoursite.com/v1/health.
Check type: Pick HTTP for websites and APIs. Pick TCP for databases, mail servers, or custom ports. Pick UDP for game servers or DNS (available on paid plans).
Check interval: How often should we check? Start with 5 minutes while you test things out. You can tighten this later. Paid plans go down to 30 seconds.
Regions: Pick where to check from. More regions give you better confidence that an alert means “the site is down globally” rather than “the site is slow from one location.”
Alert channels: Choose where alerts go. Email works for testing. Add Slack or Discord for your team. Add PagerDuty for on-call rotation.
Click “Create monitor.” That is it. Your site is now being monitored.
Step 2: Test your alerts
Do not wait for real downtime to find out if your alerts work. Test them now.
Most monitoring tools have a “test alert” button. Click it. You should get a notification in the channel you configured. If you do not, check your alert channel configuration.
For Slack or Discord, make sure the webhook URL is correct and the bot has permission to post to that channel. For email, check your spam folder and whitelist the monitoring service’s sending address.
Step 3: Configure alert settings
Alerts are only useful if they reach the right people without causing alert fatigue. Take a few minutes to tune your settings.
Alert escalation: Set a threshold so you are not paged for every transient blip. A threshold of 2 or 3 consecutive failures filters out 30-second network hiccups. You only get alerted when the problem persists.
Quiet hours: If you run scheduled maintenance on Sundays at 3 AM, set quiet hours so your team is not woken up for planned work. Quiet hours are per-monitor, so you can suppress alerts on non-critical monitors during off-hours while keeping critical ones active.
Channel routing: Different monitors, different channels. Critical production monitors go to PagerDuty. Staging monitors go to a Slack channel. Low-priority monitors go to email. This keeps your primary alert channels clean.
Step 4: Add more monitors
Your first monitor was your homepage. Good start. Now add the endpoints that matter.
Your API: If your app depends on an API, monitor the API directly. A healthy homepage does not mean a healthy API.
Your login and checkout flows: Monitor the pages where users take action, not just browse. A broken checkout costs money. A broken login locks users out.
Your database and cache: Add TCP monitors for your database port (usually 5432 for PostgreSQL, 6379 for Redis). These tell you if the service is accepting connections, not just if the server is up.
Your background jobs: Add heartbeat monitors for critical scheduled tasks. Database backups, email queues, data syncs. These run silently. If they fail, you might not notice for weeks. Learn more about heartbeat monitoring.
Your SSL certs: Add SSL monitors for every domain you own. You get alerts 30, 14, and 7 days before expiry. Certificate expiration is one of the most preventable causes of downtime. Learn more about SSL monitoring.
Step 5: Share your status page
If your monitoring tool includes status pages, set one up. A status page answers the question “is it down or is it just me?” before your users message you.
Pick which monitors appear on the page. Usually this is your public-facing services: website, API, dashboard. Internal monitors (database, background jobs) stay private.
Customize the page with your logo and colors. On paid plans, use your own domain (status.yourcompany.com). Share the URL in your app footer, your support docs, and your Twitter bio.
When an incident happens, your status page updates automatically. Users see the current state without messaging you. During the incident, post updates so users know you are working on it. Learn more about status pages.
What to do when you get an alert
Your phone buzzes. A monitor is down. What now?
First, verify it. Check the site yourself. Sometimes it really is just you. If the site loads for you but the probe reports it is down, there might be a regional network issue.
If the site is actually down, check the obvious things: did your hosting provider have an incident? Did you deploy recently? Did a certificate expire? Did you hit a rate limit or run out of disk space?
Fix the issue. Then update your status page so users know you are on it. After recovery, review the incident timeline. What failed? How long did it take to detect? How long to fix? Use this data to improve.
Next steps
You now have monitoring set up. Your site is being checked. You get alerted when things go wrong. Here is what to do next:
- Compare PingWatchdog with UptimeRobot to see how we stack up against the most popular free tool
- Set up SSL certificate monitoring if you have not already
- Learn about incident management to track downtime events automatically
Start with 15 free monitors. View our plans when you are ready for faster checks and more features.