Edesy OnCall watches websites, pages, ports and scheduled jobs on its own, and also takes alerts from Prometheus, Grafana and Uptime Kuma. When a monitor fails, an escalation policy phones your contacts in English or Hindi until one presses 1. Here is what each part does and the limits that apply.
5 monitor types
Press 1 to acknowledge
English or Hindi calls
The numbers that apply to every monitor
| Item | Edesy OnCall |
|---|---|
| Monitor types | http, keyword, tcp, heartbeat, alert webhook (ingest) |
| Check interval | Plan minimum (5 min Free, 60 s Starter, 30 s Pro) up to 24 hours |
| Timeout | 1 to 30 seconds, 10 seconds by default |
| Fail threshold | 1 to 10 failed checks in a row, 2 by default; re-check after 20 seconds |
| Heartbeat grace | 0 to 24 hours, 2 minutes by default |
| Escalation steps | 1 to 10 per policy, wait 0 to 1,440 minutes per step, repeat 0 to 10 times |
| Alert channels | Phone call and email |
| Call languages | English or Hindi, set per contact |
| Webhook endpoints | Rate limited to 120 requests a minute per IP; body up to 1 MB |
An HTTP monitor requests a URL with GET, HEAD or POST and expects a status: a class such as 2xx (the default), one code such as 200, or a list such as 200,204. Redirects are followed up to 5 times. A wrong status, a timeout or a connection error counts as a failed check.
A keyword monitor does the same request and then searches the first 1 MB of the page for your exact text. Choose present (down when the text is missing, for example Add to cart) or absent (down when it appears, for example Database error). This catches the page that returns 200 but shows an error.
Each monitor shows its last response time, the 24-hour uptime and its recent results. Details: HTTP and keyword monitors.
A TCP monitor opens a connection to a host and port (1-65535) and counts a refused or timed-out connection as a failure. Use it for services without a web page: databases, mail servers, SSH, MQTT brokers or game servers. Checks only reach public addresses; private and local network addresses are refused. Details: TCP monitors.
A heartbeat monitor turns the check around: your job calls a secret URL every time it finishes, and OnCall raises the alarm when a ping doesn't arrive within the expected period plus a grace time. It is the right check for backups, report generators, billing runs and queue workers, which fail without anyone noticing.
# crontab: run the backup every night at 02:00, ping OnCall only if it succeeded
0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://oncall.edesy.in/hb/<token> > /dev/null
Add ?status=fail&msg=... to report a failure at once instead of waiting for the ping to go missing. Build the line with the cron heartbeat URL generator, or read heartbeat monitors.
An alert webhook monitor gives you a URL that accepts alerts from the tools you already run. OnCall detects the format by itself:
| Source | How it is detected | Firing alert | Resolved alert |
|---|---|---|---|
| Prometheus Alertmanager | an alerts array |
status: firing opens an incident |
resolved closes it |
| Grafana alerting | alerts plus Grafana fields such as orgId |
firing opens an incident |
resolved closes it |
| Uptime Kuma | a heartbeat or monitor object |
heartbeat.status 0 (down) |
heartbeat.status 1 (up) |
| Any script (generic JSON) | anything else | status down, firing, critical or alert |
status up, resolved or ok |
Alerts with the same key (Alertmanager's fingerprint, or your dedup_key) update one incident instead of opening new ones. Setup guides: Grafana, Alertmanager, Uptime Kuma and generic JSON.
A policy is an ordered list of up to 10 steps. Each step has a wait time, one or more contacts, and a channel: phone call, email or both. When an incident opens, step 1 is paged at once. If nobody acknowledges before the next step's wait time is up, that step is paged, and so on. When the last step has been paged, the whole ladder can start again, up to 10 times, with a 5-minute pause between rounds.
| Example policy | Wait | Who | How |
|---|---|---|---|
| Step 1 | immediately | Developer on duty | Call and email |
| Step 2 | after 5 minutes | Second developer | Call |
| Step 3 | after 10 minutes | Engineering lead | Call |
OnCall does not have schedules or rotations: when duty changes, edit the policy. Details: escalation policies.
The alert call opens with your organisation name, then the monitor, the time it went down and a short reason. Then: press 1 to acknowledge, press 2 to escalate to the next person. Pressing 1 stops the escalation and records who took it; pressing 2 pages the next step straight away. If no key is pressed, the alert is read again once before the call ends, and escalation carries on.
The alert email has an Acknowledge button too, and anyone on the team can acknowledge or resolve an incident in the dashboard. Each contact chooses English or Hindi. Details: acknowledge and resolve.
Alerts never wait for the morning. Between 21:00 and 09:00 IST, if your workspace has the standard calling window, the alert is sent as a plain spoken call: it says what is down and asks you to open OnCall to acknowledge, but the press 1 menu isn't available. OnCall shows a banner when this happens. Ask Edesy support to enable 24x7 alert calls for your workspace and press 1 works around the clock. Tip: save your alert number as "Edesy alert" and allow it through Do Not Disturb. Details: night-time alerts.
Every incident keeps a timeline: when it opened and why, each step that was paged, each call and its outcome (answered, no answer, busy or failed), emails sent, who acknowledged and how (call, email or dashboard), and when it resolved. When a check passes again, or your tool sends resolved, the incident closes itself and everyone who was paged gets a back-up email. Contacts are verified by a code read out on a phone call, and you can place a test alert to any contact. Details: contacts and verification.
All in the OnCall portal
Sign in at oncall.edesy.in with your Edesy account and press Connect. Pick the number alerts come from and the organisation name the call starts with.
Add each person's phone, email and language. OnCall calls them with a 4-digit code to verify the number.
Order the steps, set the wait times and choose call, email or both for each step.
Create HTTP, keyword, TCP, heartbeat or alert webhook monitors and attach the policy.
Place a test call to each contact so the first real alert isn't a surprise.
Explore more comparisons, alternatives, and resources
Use cases
Integrations
Tell us what you run and how your team works. We reply within one working day with a suggested set of monitors and an escalation policy.
Connect a number, add your contacts and get your first alert call working in minutes. Prices exclude 18% GST.