How to Use ilert: A Beginner’s Guide to On-Call Alerting
CodexFuse Team · 2026-11-02T03:53:02.015Z · 15 min read
ilert turns monitoring noise into a phone call that reaches a human. This beginner’s guide walks you from signup to your first test page: alert sources, escalation policies, on-call schedules, notification channels, heartbeat monitors, and status pages.
How to Use ilert: A Beginner’s Guide to On-Call Alerting
If you are learning how to use ilert, you are really learning one mental model: monitoring tools are good at noticing problems, but they are terrible at reaching a human at 3 a.m. ilert sits in that gap. It receives events from your monitoring stack, decides which ones deserve to become alerts, and pages the right person through the channel they will actually answer — a phone call, an SMS, a WhatsApp message, or a push notification.
This guide walks you from a fresh account to your first test page in one sitting. It is an ilert tutorial — a complete ilert for beginners walkthrough, start to finish: you will create an alert source, build an escalation policy, connect notification channels, fire a test event with curl, and then extend the setup with heartbeat monitors and a status page. No monitoring tool is required to follow along — the tutorial uses ilert’s built-in API alert source so you can practice the whole workflow from a terminal.
If your observability stack currently ends at dashboards, the SigNoz beginner guide shows how metrics alerting works upstream; ilert picks up where dashboards stop — it turns “something is wrong” into “someone who can fix it has been paged.” And if you are wondering how ilert differs from incident.io: ilert decides who gets paged before the incident, incident.io coordinates the team after the page. This guide covers only the before-the-page half.
What Is ilert, Exactly?
ilert is an incident-management and on-call alerting platform: a central place where every alert from your systems lands, gets routed through escalation policies, and reaches an on-call human fast. Alert sources are the connections to your tools — Datadog, Prometheus, Checkmk, PagerDuty migrations, plain email, or a raw API — and each source hands its alerts to an escalation policy. The policy is the decision-maker: it pages the on-call rotation first, waits a few minutes, then escalates to named responders if nobody acknowledges.
Think of it as a chain with four links: the source receives the event, the policy decides who gets paged and when, the on-call schedule names the person on duty, and the notification channel delivers the page. Miss any link and the chain breaks, which is why this tutorial sets up all four in order. The company behind it is Berlin-based, the docs ship an official quick-start that claims ten minutes to a real alert on your phone, and the free plan genuinely covers a small team — up to five users with one escalation policy, one on-call schedule, and 100 SMS or voice notifications a month.
How Do You Set Up ilert in Six Steps?
Here is the complete beginner arc, in the order the official quick-start teaches it. Each step below gets its own section with the details, but this list is the shape of the whole job:
- Create your free ilert account and complete the 14-day full-feature trial setup.
- Add your phone number and install the mobile app, then send a test notification to every channel.
- Create your first alert source using the API integration — no monitoring tool needed.
- Generate your first escalation policy and preview who gets paged when.
- Send a test event with curl and watch your phone ring.
- Accept and resolve the alert so you understand the full alert lifecycle.
Once those six steps work, the optional seventh and eighth are heartbeat monitors (for things that should keep pinging) and a status page (for telling your users what is broken). That is the whole platform from a beginner’s point of view.
Step 1: Create Your Free ilert Account
Sign up at app.ilert.com. ilert starts every account on a 14-day free trial of the full feature set, and no credit card is required — a sensible way to run this entire tutorial without paying anything. After the trial, the free plan is built for small teams: up to five users, unlimited email, push, and messenger notifications, 100 SMS or voice notifications per month shared across the account, one on-call schedule, one escalation policy, three responders per escalation level, one heartbeat monitor, and one limited public status page.
Two things to note before you click around. First, pricing figures move — this page’s numbers were current when this guide was written, so check the pricing page itself if you are planning around exact limits. Second, only one free plan is allowed per company, so use your team’s real workspace for this tutorial rather than a throwaway account you will abandon.
Step 2: Connect Your Notification Channels
Your notification channels are set up before anything else, because an alert source with no verified channel is just a silent alarm. Open the user menu, go to Notification settings, and add your phone number — one verified number unlocks voice calls, SMS, and WhatsApp. Then install the ilert mobile app on iOS or Android for push notifications, which is the fastest channel for most people.
Now verify each channel instead of trusting it. ilert has a “Send test notification” action — use it once per channel and confirm the message actually arrives on your device. While you are there, look at Notification rules: you can treat high-priority and low-priority alerts differently, so a critical page rings your phone while a low-priority one just pushes a quiet notification. Unverified channels are the single most common reason a first alert seems to “not work,” and it is a thirty-second fix.
Step 3: Create Your First Alert Source
An alert source is the connection between a monitoring tool and ilert: it receives events, decides whether each one becomes an alert, and hands the alert to an escalation policy. The reason ilert alert sources exist as a separate concept is grouping and routing — the same noisy tool can feed different policies for different systems. For this tutorial you will use the API integration, which needs no monitoring tool at all — you will send events yourself with curl.
Go to Alerting, then Alert sources, then Create new alert source, and pick API. Name it after the system it watches, not the tool that sends the events — “Checkout API” beats “Prometheus,” because when five sources fire at once, system names tell you what is actually broken. You can also assign the source to a team here if your workspace has more than one.
Next the wizard asks who gets notified: pick an existing escalation policy or let it generate a new one for you, and it will preview the escalation chain so you can see the whole page order before saving. Then choose event grouping — Smart grouping uses AI to merge related events, Time-based grouping merges events inside a window, and Default grouping merges by alert key. Auto-resolution is optional and worth enabling later: it closes the alert automatically when the resolving event arrives instead of leaving stale alerts open.
When you finish, open the alert source’s detail page and find the integration key. Treat this key like a password: anyone holding it can raise alerts in your workspace. If it ever leaks, hit the regenerate icon on the same page and update your senders.
Step 4: Build Your First Escalation Policy
An escalation policy is the document that answers “who gets paged, and when.” Your first ilert escalation policy should be boring on purpose: page the person currently on the on-call schedule first, wait a fixed number of minutes, and if nobody acknowledges, escalate to the next level — a named responder or the whole team. The wizard preview shows this chain end to end, which is the moment to check that the right people are in it.
Behind the policy sits the on-call schedule, which names who is on duty when. ilert on-call schedules are what make the policy page a person instead of a list — without a schedule, the policy has nobody to page first. Start with one simple rotation — weekly is fine for a small team — and only add complexity (follow-the-sun, holiday overrides, multiple teams) after the basic page reaches a human reliably. Teams that run Kubernetes often route cluster alerts into ilert this way; the Kubernetes beginner guide covers the orchestration side, while ilert handles the human side.
The free plan allows exactly one escalation policy and one on-call schedule, with up to three responders per escalation level — plenty for a first setup, and the constraint actually helps, because it forces you to design one clean chain instead of five confusing ones.
Step 5: Send Your First Test Page
Sending a test event is one curl command. Replace YOUR_INTEGRATION_KEY with the key from your alert source’s detail page and run it from any terminal:
curl -X POST https://api.ilert.com/api/events \
-H "Content-Type: application/json" \
-d '{
"integrationKey": "YOUR_INTEGRATION_KEY",
"eventType": "ALERT",
"summary": "Refund webhook backlog above threshold",
"details": "3,412 refund webhooks pending delivery. Oldest is 18 minutes behind."
}'
Only three fields are required: the integration key, the event type, and the summary. Authentication lives in the request body — there is no Authorization header on this endpoint. The other event types are ACCEPT and RESOLVE, which is how external systems acknowledge or close alerts. Optional fields include details (which supports Markdown), alertKey for grouping related events, priority (HIGH escalates, LOW does not), images, links, customDetails, and routingKey, which can override the escalation policy with one that has a matching key.
Expect a 202 Accepted with an empty body — and do not mistake that for “an alert was created.” A 202 only means the event was received; whether it became an alert is decided downstream, and you can watch that decision in the alert source’s Alert source logs tab. Keep the correlation-id response header handy in case you ever need support to trace the event.
If your phone rings, the whole chain works: event, source, policy, schedule, channel. In the ilert console the new alert starts as PENDING. Accepting it halts the escalation immediately — that is the button you will reach for at 3 a.m. — and resolving closes it for good. A resolved alert cannot be reopened; the next event for the same problem creates a brand-new alert, which keeps your history honest.
Once the manual test works, real sources follow the same shape. CI pipeline failures are a natural second source: the GitHub Actions beginner guide covers the pipeline side, and any job that can run curl on failure can post an ALERT event to the same endpoint.
What Are ilert Heartbeat Monitors?
A heartbeat monitor alerts you when something that should keep pinging ilert on a schedule stops pinging. It is the right tool for cron jobs, background workers, and scheduled tasks — anything where the failure mode is silence rather than an error message. Dead-man’s-switch monitoring, in other words: the absence of the signal is the signal.
Setup is quick and lives in its own navigation section. Create a heartbeat monitor, give it a name, choose the interval after which a missed ping raises an alert, attach an alert source, and write the alert summary you want to receive. The timer starts on the first ping, so the monitor does nothing until your system actually starts reporting in. Your system only needs HTTPS outbound access to send pings — no inbound firewall rules, no agent to install. If you host your own stack, the VPS hosting guide covers the server side; the heartbeat is the five-minute addition that tells you when the cron job on that server quietly died. The free plan includes one heartbeat monitor, with extras available on paid plans.
What Are ilert Status Pages?
A status page is the public face of your incidents: a page where users check whether your service is up, read updates during an outage, and subscribe to notifications. Create one with the wizard — pick the page type first, because Public, Private, and Audience-specific are fixed once the page is activated. Then set the name, claim your yourname.ilert.io address, choose the timezone and teams, add your services and logo, preview it, and click Activate. The number one support question about status pages is “why can’t I reach my page,” and the answer is almost always that the Activate click was skipped.
Status pages carry service states, written status updates, metrics, and scheduled maintenance windows, and they can update themselves: the “Update status page” alert action lets a monitoring alert post to the page automatically. Custom domains work over CNAME with automatic SSL, and subscribers can follow by email or RSS on every plan, with SMS subscriptions on the higher tiers. The free plan includes one limited public status page — enough to communicate outages honestly while your team is small.
ilert vs PagerDuty: Should a Beginner Care?
As a beginner, no — and that is the honest answer. PagerDuty defined this category and remains the default at large enterprises, but the decision factors that matter at enterprise scale (SSO depth, hundreds of integrations, global support contracts) do not apply to a team learning on-call for the first time. ilert’s free tier pages a real five-person team with real phone calls, which is all a beginner setup needs to prove.
The comparison becomes interesting later, around three questions: budget per responder, which notification channels your team actually answers, and whether you want a European vendor. Run the free tier for a month with real alerts before shopping — you will learn more about your paging needs from thirty days of actual pages than from any feature matrix.
7 Mistakes Beginners Make with ilert
Every one of these comes from real first-week setups. The fixes are all one-minute jobs once you know them:
| Mistake | Why it hurts | The fix |
|---|---|---|
| Naming the alert source after the tool (“Prometheus”) | Five sources fire and you cannot tell which system is broken | Name sources after the system: “Checkout API,” “Primary database” |
| Skipping the test notification | You discover at 3 a.m. that your number was never verified | Use “Send test notification” on every channel today |
| Treating 202 Accepted as “alert created” | The event was received but never became an alert, and you never notice | Check the alert source’s Alert source logs tab after each test |
| One flat policy paging everyone at once | Page storms; nobody knows who owns the incident | One on-call rotation first, timed escalation to named responders |
| Forgetting to click Activate on the status page | The page is unreachable and users see nothing during an outage | Activate, then open the public URL in a private window |
| Pasting the integration key into chat or tickets | Anyone with the key can raise alerts in your workspace | Treat it like a password; regenerate it from the source’s detail page |
| Leaving auto-resolution off | Alerts pile up long after the incident self-healed | Enable auto-resolution on the alert source once grouping looks right |
Sources
- ilert official quick-start guide — docs.ilert.com/getting-started/quick-start-guide (alert-source wizard, escalation policy preview, test alert curl, notification settings, ~10-minute claim; fetched 2026-11-02)
- ilert Events API samples — docs.ilert.com/developer-docs/api-samples/creating-alerts-through-events (eventType values, optional fields, no Authorization header, 202 semantics; fetched 2026-11-02)
- ilert pricing page — ilert.com/pricing (free-plan limits: 5 users, 100 SMS/voice per month, 1 escalation policy, 1 on-call schedule, 1 heartbeat monitor, 1 limited status page; Pro $19/user/mo; fetched 2026-11-02)
- ilert heartbeat monitoring docs — docs.ilert.com/alerting/heartbeat-monitoring (separate nav entity, timer starts on first ping, HTTPS outbound only; fetched 2026-11-02)
- ilert status pages docs — docs.ilert.com/incident-comms-and-status-pages/status-pages (page types fixed after activation, Activate requirement, yourname.ilert.io; fetched 2026-11-02)
- rtfm.co.ua — “ilert: an alternative to Opsgenie” (independent hands-on: Alertmanager to ilert to Slack in about fifteen minutes; fetched 2026-11-02)
Frequently Asked Questions
Is ilert free for a small team?
Yes, with real limits. Every account starts with a 14-day full-feature trial that needs no credit card, and the free plan after that covers up to five users with unlimited email, push, and messenger notifications, 100 SMS or voice notifications per month across the account, one escalation policy, one on-call schedule, one heartbeat monitor, and one limited public status page. Pricing figures move, so confirm the current limits on the pricing page before planning around them.
Can I try ilert without owning a monitoring tool?
Yes — that is exactly what this guide does. The API alert source plus one curl command is the official way to practice: you can walk the entire chain from event to phone call to resolution without installing or connecting anything else. Connect your real monitoring tools only after the manual path works.
What notification channels can actually page me?
Voice calls, SMS, WhatsApp, Telegram, mobile push, email, and chat tools like Slack and Teams. Add and verify your phone number for the call, SMS, and WhatsApp channels, install the mobile app for push, and use the “Send test notification” action once per channel before you trust any of them with a real incident.
What is the difference between ilert and incident.io?
They cover opposite sides of the incident. ilert decides who gets paged before the incident is acknowledged — alert sources, escalation policies, on-call schedules. incident.io coordinates the team after the page — declaring the incident, assigning roles, and writing the timeline. Most growing teams eventually use both, one for paging and one for response.
Does a 202 response mean my alert was created?
No. A 202 Accepted with an empty body only confirms that ilert received your event; whether it became an alert is decided downstream by the source’s grouping and routing rules. Check the alert source’s Alert source logs tab to see the outcome, and keep the correlation-id response header in case you need support to trace the event.