Business Hours Schedules
Defer non-urgent alerts until your preferred weekdays and hours to avoid burning out your on-call team with 3am wake-ups.
Business hours schedules:
Many issues are important to fix, but can realistically wait until the morning, or until Monday morning. We call these “important-but-not-urgent”.
That’s why we built Business Hours Schedules, which you can enable on a per-monitor basis, to defer specific alerts until your team’s preferred business hours.
Flexible alerting:
Matching your alerting strategy to the severity of the issue is key to avoiding on-call burnout.
For urgent issues, HeyOnCall uses Critical Alerts, which use special phone permissions to bypass Do Not Disturb, silent/vibrate modes, and volume settings. They’re loud and impossible to ignore, and will repeat until acknowledged.
For less urgent issues, you have the flexibility to use regular push notifications, customize the repeat interval, defer until business hours, disable escalation rules, and more.
TLDR:
Built for small engineering teams and solo founders, HeyOnCall delivers reliable and impossible-to-ignore on-call alerts. With business hours schedules and other features for lower-intensity alerting, our service helps your team deliver reliability while avoiding burnout. HeyOnCall is designed from the ground up to reduce false positive alerts (getting alerted when your site is actually up) and false negatives (missing an outage due to broken monitoring or alerting).
Business Hours Schedules: HeyOnCall vs. Alternatives
| Differentiator |
HeyOnCall
|
Alternatives |
|---|---|---|
| Business hours schedules | Defer important-but-not-urgent alerts (like a certificate expiring in two weeks) until your preferred weekdays and hours. | No differentiation between urgent and non-urgent alerts. Burns out your on-call team waking them up for things that can wait until the morning. |
| Alerting | iOS/Android “Critical Alerts” bypass Do Not Disturb and volume/mute settings. Repeat until acknowledged. Will wake you up! | No mobile app. No critical alerts. Emails or Slack alerts are easy to miss for hours. |
| On‑call | Integrated on-call rotation schedules and escalations. | Separate products for monitoring and on-call: requires integration glue between them, so there are more moving parts to fail during an outage. |
| Mobile apps | Lightweight mobile apps for iOS and Android. Designed to reliably deliver alerts and let you quickly acknowledge the incident. | ¯\_(ツ)_/¯ |
| Silencing | Quick silence with selectable timeout at the trigger, service, or organization-wide level. Ensures you don’t keep getting alerts while you’re fixing the issue, and ensures you don’t inadvertently stay silenced forever. | Mute one monitor at a time. Forget to unmute after the incident is over, so you miss the next incident. |
| False positives (noisy alerts) |
Customer-level: False positives are reduced to your preferences via customizable consecutive-failure thresholds / timeouts. Platform-level: False positives are reduced through continuous control group self-checks, extensively tested codebase, and code paths designed to differentiate our network incidents from yours. |
¯\_(ツ)_/¯ |
| False negatives (missed alerts / blind spots) |
Customer-level: Missed alerts are reduced via: alerts repeat until acknowledged; configurable multiple delivery channels per user; configurable multi-level escalations. Blind spots are reduced via configurable assertion rules on HTTP response headers, etc. Platform-level: False negatives are reduced via extensive CI test suite, continuous production self‑checks, and external monitoring. |
Customer-specific glue (webhook integration) between separate monitoring product and on-call product fails silently (webhooks/auth headers/network issues), resulting in missed alerts right when you need them. |
| Pricing | Simple, flat $/month pricing. Free tier forever. | Annoying $/user/month or $/monitor/month. |
Business Hours Schedules FAQ
Why do I need business hours schedules?
If your alerting solution doesn't let you customize your alerting strategy to the severity of the issue, there are real consequences: you might skip monitoring important-but-not-urgent issues entirely (letting failures go unnoticed much longer than necessary), or you might burn out your team by waking them up at 3am for issues that could have waited.
Business hours schedules are one tool to help your team avoid notification fatigue, while still having confidence that all your systems are being monitored and nothing will slip through the cracks.
What are important-but-not-urgent issues?
Important-but-not-urgent issues are issues that are important to fix, but can realistically wait until the morning, or until Monday morning.
What are some examples of important-but-not-urgent issues?
Sometimes it's a matter of degree. For example, an SSL certificate expiring in 14 days can wait until Monday morning, but a certificate expiring in under 24 hours is probably worth waking someone up to fix.
Sometimes it's a matter of production impact. For example, a backup script that fails is definitely important to fix, but may not be worth waking someone up at 3am.
How do I define a business hours schedule?
In the HeyOnCall dashboard, you can define a timezone-aware schedule for each day of the week, with open and close times for each day.
Can I exclude one-off days from my business hours schedule?
Yes. For team holidays, just add the dates to the “Excluded Dates” field.
Can I have multiple business hours schedules?
Yes. This may help if you have entire teams that operate in different time zones or covering multiple shifts.
Do business hours schedules apply to all alerts?
No. Once you define the schedule, it's still opt-in on a per-monitor basis. You have the flexibility to choose which monitors will take advantage of deferring alerts until business hours.
Are business hours schedules compatible with escalations?
Yes. We have an extensive internal test suite covering combinations of business hours schedules and escalation rules. Escalation rules will also be deferred appropriately.
Are deferred alerts still visible in the dashboard?
Yes. An incident will be created and will be visible in the dashboard and in our mobile apps, even if the on-call alert for that incident is being deferred until later.
Additionally, if you've configured team-wide webhook or Slack integrations for new incidents, they will still be delivered when the incident is created, even if the on-call alert for that incident is deferred until later.
What makes HeyOnCall better than alternatives?
Alternative solutions often require you to stitch together separate monitoring and on-call alerting tools using brittle webhooks between them. For example: would you really trust your self-hosted monitoring server to be able to send a POST request to your third-party alerting service exactly when you’re in the middle of a flaky network outage? :facepalm: Not exactly a recipe for reliability.
HeyOnCall integrates website monitoring, heartbeat monitoring, on‑call schedules, and alert delivery in one product, which removes fragile links and makes the overall system more reliable.
Critical alerts. On-call schedules. Escalations. Monitoring for websites, APIs, cron jobs, and SSL certificates. All built-in and battle-tested. Designed for developers, by developers. Simple, flat pricing. Free tier forever.
How fast can I get started?
Sign up (free tier forever), download the iOS/Android app, and send yourself a test notification delivered in seconds.
Live sandbox resets hourly.
No sign-up required.
No credit card required.
Free tier forever.