Blog · Uptime
Uptime monitoring and error tracking in one tool
An uptime monitor tells you the site is down. An error tracker tells you why. Keeping them in two tools means two dashboards, two sets of alerts, and a lot of tab switching at 3 a.m.
Three tools for one question
A typical small team ends up with an error tracker, a separate uptime monitor, and maybe a third service for cron jobs - plus a status page from yet another vendor. Each one is fine on its own. Together they answer the same question - is my app working? - from three dashboards that don't know about each other.
When the API goes down, the uptime tool pages you. The error tracker fills with connection errors from the front end. Neither links to the other, and you piece the story together by hand.
What a good uptime check does
The point of an uptime monitor is to wake you up for real outages and never for a dropped packet. In BugCatch each HTTP monitor works like this:
| Behaviour | Value |
|---|---|
| Check interval | Every 5 minutes |
| Request timeout | 10 seconds |
| Retries before marking down | 3, spaced 5 seconds apart |
| Uptime window | Rolling 24 hours |
A URL is only reported down after the first check and all three retries fail. Response time is recorded on every check, so you can see a service getting slower before it falls over.
SSL certificates and domains
Turn on checkSsl and every check also reads the certificate's expiry date. You get one email a day once it has 30 days or less left, with the exact day count. checkDomain does the same for the domain registration - useful because a certificate can auto-renew while nobody notices the domain itself is about to lapse.
Cron jobs: the monitor that waits for you
Some things can't be checked from the outside: a nightly backup, a queue worker, an export that runs every hour. For those, the job checks in instead. If BugCatch doesn't hear from it on time, it alerts - the "dead man's switch" pattern.
No SDK is needed. Add one line to the end of the job:
# crontab: run the backup at 02:00, then check in
0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://api.bugcatch.app/cron/YOUR_MONITOR_ID/pingSet the expected interval and a grace period. A job that should ping every hour, with the default 5-minute grace, is reported down if 66 minutes pass without a ping. There are also /start and /fail endpoints if you want run durations or an explicit failure.
A status page your users can check
Each project gets a public page at bugcatch.app/status/your-slug. You choose which uptime and cron monitors appear on it and give them public names - prod-health-check-v3 can read "API". When something breaks, post an incident and update it as you go: investigating, identified, monitoring, resolved.
It's the page you link to instead of answering the same question in five DMs.
Why it helps to have it all in one place
- One set of alerts. Downed monitors, new issues and threshold alerts each have their own cooldown, so one bad afternoon doesn't turn into fifty emails.
- The cause is next to the symptom. When a monitor goes down, the errors your app reported in the same minutes are in the same project.
- One bill. Uptime and cron monitors share one limit on your plan: 3 on Starter, 20 on Pro, unlimited on Business.
- On your phone. The BugCatch mobile app pushes monitor and issue alerts, with quiet hours per device.
Setting it up
Open your project, go to Monitors, and add the URL you want checked - usually a health endpoint such as /health rather than the home page. Add a cron monitor for each scheduled job, then pick which ones go on the status page. Monitors are available from the Starter plan (€4 a month), and every paid plan starts with a 14-day Pro trial.