FlowRunner
PricingContact
Theme
Start Free

ilert is an incident management, on-call alerting, and status page platform. Agents post events and alerts, accept or resolve them, look up who is on call, manage escalation policies, schedules, and maintenance windows, and update status pages.

Verified 163 actions API key available
ilert website Platform Documentation Capability data verified 2026-08-25
A monitoring check fails and posts to ilert's events API
Post Event opens or updates one alert, deduplicated on its alert key rather than opening a new one per minute
Get Current On-Call User resolves who the rota says is covering right now
List Notification Preferences confirms that person has a live Alerts preference, since a responder with none is unreachable
Add Alert Responder pulls in a second responder when the first has no working channel
Forecast Incident Publication reports how many status page subscribers a public notice would reach
The incident commander decides whether to publish and notify

What This Integration Enables

ilert splits into two halves that most teams treat as one system and should not. The first half decides who gets woken up: alert sources, escalation policies, on-call schedules, teams, and the notification preferences that say through which channel and after how long. The second half decides what customers are told: services, incidents, status pages, subscribers, and maintenance windows. The connector covers both completely, at 163 operations, and the interesting automation lives in the seam between them.

That seam has a specific and well-known failure. An escalation policy level names a user, a schedule, or a team. Whether that person is reachable is decided somewhere else entirely, in their own notification preferences, and neither half warns you about the other. A responder on the rota with no Alerts preference is simply unpageable, and nothing in the schedule, the policy, or the alert says so. FlowRunner agents close that gap by checking reachability as a standing routine rather than as an incident finding, and by keeping the alerting surface itself current: creating and repointing alert sources, adding schedule overrides for a swap, opening maintenance windows so planned work does not page anybody. On the customer-facing half, the agent prepares everything and stops, because publishing is a public act. That is the digital andon cord working as intended: the line keeps running, and the moment that needs a person is the moment a person is asked.

Without FlowRunner

The rota looks staffed Somebody is on the schedule, and nothing checks whether ilert can actually reach them tonight
Alerts multiply A check failing every minute opens an alert every minute, and the real signal is buried in its own repetitions
The status page is an afterthought Customers learn from the support queue, because updating the page is a manual step somebody does last

With FlowRunner

Reachability verified before it matters On-call cover and notification channels are checked ahead of the page, not discovered during one
One alert per problem Recurring signals deduplicate onto a single alert that updates, acknowledges, and resolves itself
Public communication prepared, then chosen The incident text, the affected services, and the audience size are ready before anyone decides to publish

Use Case Scenarios

  • An on-call rota that is checked before it is needed

    Every morning the agent calls List On-Calls to read who is covering across every policy and schedule in one query, which is the operation that answers "who is on call right now" without walking each schedule. For each of those people it reads List Notification Preferences and List User Phone Numbers, and anyone with no live Alerts preference or no verified number becomes an exception rather than a statistic. It cross-checks the escalation policies with Get Escalation Policy so that a level pointing at a deleted schedule is caught while it is a maintenance task rather than during a page. The findings post to the reliability channel in Slack, and where the rota has a genuine hole, Add Schedule Override is the operation that fills it once a person names the cover.

  • Deploys, alerts, and the question of what changed

    A pipeline in GitHub or CircleCI finishes a production release, and the agent calls Post Deployment Event against the matching pipeline. That is a small call with a large payoff: alerts raised soon afterward show the deployment on their own timeline, which usually answers what changed without anybody investigating. When an alert does open from Datadog or Grafana, the agent enriches it before a human ever reads it. Create Chat Message posts the correlated deploy, the recent related alerts, and the runbook link into the alert's own chat channel, and the alert action that opens the ticket in Jira is invoked in the same pass. The responder wakes to context rather than to a subject line.

  • Planned work that does not page anybody

    A maintenance window is scheduled, and the naive automation is to deactivate the alert sources involved. That does half the job and leaves them off until somebody remembers. Create Maintenance Window is the correct operation: it mutes the listed alert sources and marks the listed services as under maintenance for a fixed period, then undoes itself. The agent builds the window from the change record, and if the work overruns it extends the window with Update Maintenance Window rather than opening a second one. Afterward it reads Get Service Outages to see what was recorded, and where a monitoring artifact was logged as real downtime, Create Service Outage Override is available to correct the uptime history. Every one of those corrections is a deliberate rewrite of what a customer-facing number says, so the agent proposes them and a person applies them.

Human-in-Loop Highlight

ilert ships its own gate, and it is worth using rather than replacing. Create Incident and Update Incident with Send Notification on will email and text every subscriber to the affected services and status pages, and there is no staged rollout and no recall. Forecast Incident Publication answers the question that ought to precede that: it reports exactly which subscribers and which status pages the incident would reach, publishes nothing, and sends nothing. A vendor that builds a dry run for one specific operation is telling you which operation deserves one.

So the agent assembles the whole incident and stops at the forecast. It has already resolved the affected services, chosen the incident template so the wording matches how this team writes about outages, and set every affected service's target status. Then it asks: "Payments API has been failing checks for 11 minutes and the alert is unacknowledged at escalation level two. A status page incident using the Degraded Performance template would reach 3,412 subscribers across two public pages, one of which is the customer-facing page for enterprise accounts. Publish with notification, publish quietly without notification, or hold?" The commander answers in one message. The agent then handles what follows, including the part teams forget: resolving an incident does not clear the service impacts, so every affected service has to be set back to operational in the same call or the page stays red with no open incident explaining it.

Two adjacent operations sit behind the same reasoning. Update Service with a status set is a public act with no incident attached, which is how a status page turns red with nothing to explain it. And Create Alert Action in Automatic mode with no alert-source scope and no conditions fires on every alert in the account, which is how a test action ends up filing a ticket for the entire estate.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via email
Human decides
Agent resumes with decision

Agent Capabilities

163 actions

Events

2
  • Post Event Sends an event to the events API, which is how a monitoring tool raises, acknowledges, or resolves an alert. Events deduplicate on the alert key, so a check firing every minute updates one alert rather than opening thousands. Keyed on the alert source's integration key.
  • Post Deployment Event Records a deployment against a pipeline so that alerts raised soon afterward are correlated with the release. The deployment appears on the alert's timeline, which usually answers what changed.

Alerts

12
  • List Alerts Returns alerts newest first, with filters on state, source, policy, responder, and time range. Filtering on pending is how a flow finds work nobody has acknowledged.
  • Count Alerts Returns just the number of alerts matching the filters. Use it when a flow only needs to know whether anything is open.
  • Get Alert Returns one alert with its status, priority, source, assignee, responders, and details.
  • Create Alert Opens an alert directly against an alert source id. It does not deduplicate, so reserve it for a genuine one-off and use Post Event for anything recurring.
  • Accept Alert Acknowledges an alert, which stops the escalation clock.
  • Resolve Alert Closes an alert.
  • Assign Alert Reassigns an alert to a user, an escalation policy, or a schedule. Exactly one of those.
  • List Alert Log Entries Returns the timeline of everything that happened to an alert. Filtered to notifications, it answers whether anybody was actually paged and through which channel.
  • List Alert Notifications Returns every notification sent for an alert, with the channel, the target contact, and the delivery outcome.
  • List Suggested Responders Returns the users ilert suggests as responders, which is the set Add Alert Responder can draw from.
  • Add Alert Responder Pulls an additional user into an alert, notifying them through their own preferences.
  • Remove Alert Responder Takes a user off an alert's responder list, stopping further notifications to them about it.

Alert sources

6
  • List Alert Sources Returns the configured alert sources with their integration type, key, escalation policy, and grouping.
  • Get Alert Source Returns one alert source with its integration key and URL, policy, grouping, and templates.
  • Create Alert Source Registers a new source, which is what a monitoring tool sends events to.
  • Update Alert Source Changes a source's routing, grouping, and templates. The integration type cannot be changed after creation.
  • Delete Alert Source Removes a source permanently. Its integration key stops working immediately, so every monitor posting to it fails silently from that moment.
  • List Integrations Returns the inbound and outbound integrations ilert supports, which is the authoritative list of integration types.

Alert actions and connectors

12
  • List Actions For Alert Returns the actions that can be invoked on a specific alert, with the history of ones already run.
  • Invoke Alert Action Runs a manual action against an alert, such as opening a ticket or a channel.
  • List Alert Actions Returns the account's alert actions with their connector, trigger mode, trigger types, and filters.
  • Get Alert Action Returns one alert action's full configuration, including which alert sources it applies to.
  • Create Alert Action Creates a rule that runs something in an outside system when an alert changes. In automatic mode with no source scope and no conditions, it fires on every alert in the account.
  • Update Alert Action Changes an action's routing, triggers, scope, or payload. Trigger types and source scope are replaced rather than merged.
  • Delete Alert Action Removes an alert action, and with it whatever downstream ticket or message it was creating.
  • List Connectors Returns the connectors in the account. A connector holds the credentials for an outside system that alert actions run against.
  • Get Connector Returns one connector with its type and parameters.
  • Create Connector Registers a connector holding credentials for an outside system.
  • Update Connector Changes a connector's name or credentials. The type cannot be changed.
  • Delete Connector Removes a connector, which stops every alert action built on it.

Escalation policies

7
  • List Escalation Policies Returns the policies with their rules, repeat settings, and routing keys.
  • Get Escalation Policy Returns one policy with every level, the users, schedules, and teams on each, and its routing key.
  • Resolve Escalation Policy By Routing Key Looks a policy up by its routing key rather than its id. Routing keys are stable and human-chosen, which makes them the better reference in a flow.
  • Create Escalation Policy Creates a policy from a list of escalation rules, each carrying its own timeout.
  • Update Escalation Policy Replaces a policy's name, rules, repeat behavior, and routing key. Sending rules replaces the entire ladder.
  • Replace Escalation Level Rewrites a single level in place, leaving the other levels untouched. The safer operation when only one level is changing.
  • Delete Escalation Policy Removes a policy. Alert sources routing through it have to be repointed first.

On-call schedules

10
  • List Schedules Returns the on-call schedules with their type, timezone, current shift, and next shift.
  • Get Schedule Returns one schedule with its layers and shifts.
  • Get Current On-Call User Returns the user currently on call on a schedule, wrapped in the shift they are covering. The direct answer to who is covering right now.
  • List Schedule Shifts Returns a schedule's shifts for a date range, which is how a flow reads the rota forward or reconstructs it backward.
  • List Schedule Overrides Returns the one-off swaps that replace the normal rotation for a period.
  • Add Schedule Override Puts a specific user on call for a period, overriding the rotation. The cover-me operation.
  • Create Schedule Creates an on-call schedule. Recurring and static schedules take different input.
  • Update Schedule Changes a schedule's name, timezone, layers, or shifts. Sending layers or shifts replaces those lists outright.
  • Delete Schedule Removes a schedule. Escalation policy levels pointing at it are left targeting nothing, which is one of the ways a rota looks staffed and is not.
  • List On-Calls Returns who is on call across policies, schedules, and users for a time range, in one query. The operation a daily reachability check should start from.

Users and contacts

15
  • List Users Returns the users in the account with their names, emails, roles, and timezones.
  • Get User Returns one user by id.
  • Get Current User Returns the user the API key belongs to, which is also how a flow discovers which identity its writes will be attributed to.
  • Find User By Email Looks a user up by email, which is the reliable way to turn an identity a flow already holds into an ilert user.
  • Update Current User Changes the profile of the key's own user without needing admin rights.
  • Create User Adds a user to the account. Requires admin privileges on the API key.
  • Update User Changes a user's profile, role, timezone, language, or region.
  • Delete User Removes a user. Their on-call cover is worth checking first, since deleting the only person on a schedule leaves it uncovered.
  • List Notification Numbers Returns the numbers ilert places voice and SMS notifications from, which is the list responders should be told to allow.
  • List User Phone Numbers Returns a user's phone contacts, which are the targets for voice and SMS notifications.
  • Create User Phone Number Adds a phone contact so ilert can call or text a user. The number has to be in international format.
  • Delete User Phone Number Removes a phone contact. Notification preferences that targeted it stop working.
  • List User Emails Returns a user's additional email notification targets, which are separate from their login address.
  • Create User Email Adds an extra email notification target to a user.
  • Delete User Email Removes an email notification target, and with it any preference pointing at it.

Notification preferences

3
  • List Notification Preferences Returns one kind of a user's notification preferences: how and how soon they are told. The operation that answers whether a person on the rota is actually reachable.
  • Create Notification Preference Adds a notification rule to a user, such as push immediately and call after five minutes.
  • Delete Notification Preference Removes one rule. Deleting a user's only Alerts preference makes them unpageable, with nothing elsewhere saying so.

Teams

7
  • List Teams Returns the teams with their visibility and members. Team ownership is what scopes a team-scoped API key.
  • Get Team Returns one team with its members and each member's team role.
  • Create Team Creates a team and optionally seeds its members.
  • Update Team Renames a team, changes its visibility, or replaces its member list. Sending members replaces the whole list.
  • Add Team Member Adds one user with a team role, leaving existing members alone. The safer operation for a single change.
  • Remove Team Member Takes a user out of a team, along with the cover the team gave them.
  • Delete Team Removes a team. Resources it owned lose their owner, and keys scoped to it stop working.

Services and outage history

12
  • List Services Returns the services in the account with their current status. A service is the customer-facing component a status page lists.
  • Get Service Returns one service with its status, description, and settings.
  • Create Service Creates a service. Its alias is the stable, URL-friendly reference to use in a flow.
  • Update Service Changes a service, including its published status. Setting a status here is a public act with no incident to explain it, so prefer Create Incident with affected services.
  • Delete Service Removes a service. It disappears from every status page that carried it, taking its uptime history with it.
  • List Service Subscribers Returns the users and teams subscribed to a service's status changes.
  • Set Service Subscribers Replaces a service's internal subscriber list. Anyone not in the call is unsubscribed.
  • Get Service Outages Returns the outage periods recorded against a service, with any manual overrides applied. What the published uptime figure is computed from.
  • List Service Outage Overrides Returns the manual corrections applied to a service's outage history. Each one is somebody deliberately changing a published number.
  • Create Service Outage Override Rewrites part of a service's recorded outage history, for example to discount a period that was a monitoring artifact.
  • Update Service Outage Override Changes an existing correction, including its status and period.
  • Delete Service Outage Override Removes a correction, restoring the raw recorded history and the original uptime figure.

Incidents

7
  • List Incidents Returns status page incidents with their state, message, and affected services.
  • Get Incident Returns one incident with its full message, state, and affected services.
  • Create Incident Publishes a status page incident and, through affected services, sets the status those services show. With notification on, it emails and texts every subscriber.
  • Update Incident Posts an update to an incident: a new state, a new message, or a change to which services it affects. Resolving does not clear the service impacts, which have to be set back in the same call.
  • Forecast Incident Publication Reports which subscribers and status pages an incident would reach, without publishing anything or sending anything. The vendor's own dry run, and this page's human gate is built on it.
  • List Incident Subscribers Returns the users and teams internally subscribed to an incident.
  • Add Incident Subscribers Adds users and teams to an incident's internal subscriber list, leaving the existing ones alone.

Incident templates

5
  • List Incident Templates Returns the reusable incident templates, which are how a team keeps its outage wording consistent under pressure.
  • Get Incident Template Returns one template with its default summary, status, message, and notification flag.
  • Create Incident Template Saves a reusable template. It carries the notification flag with it, so a template saved with notification on notifies every time it is used.
  • Update Incident Template Changes a template's wording, default state, or notification flag.
  • Delete Incident Template Removes a template. Incidents already created from it are unaffected.

Status pages

13
  • List Status Pages Returns the status pages with their domain, visibility, and current aggregate status.
  • Get Status Page Returns one page with its services, metrics, structure, and appearance.
  • Create Status Page Creates a page carrying a set of services. A public page is reachable by anyone who has the address.
  • Update Status Page Changes a page's services, branding, visibility, or activation. Sending service ids replaces the list, and turning activation off takes a live page down while people are reading it.
  • Delete Status Page Removes a page permanently along with its subscriber list, which is not recoverable.
  • List Status Page Groups Returns the service groups on a page, which are the headings services sit under.
  • Create Status Page Group Adds a group heading to a page. Creating it does not put any service in it.
  • Update Status Page Group Renames a group on a page.
  • Delete Status Page Group Removes a group. The services survive and fall back to being ungrouped.
  • List Status Page Subscribers Returns the ilert users and teams internally subscribed to a page.
  • Add Status Page Subscriber Subscribes one user or team, leaving existing subscribers alone.
  • Remove Status Page Subscriber Unsubscribes one user or team.
  • Set Status Page Subscribers Replaces a page's internal subscriber list outright, unsubscribing anyone missing from the call.

Maintenance windows

5
  • List Maintenance Windows Returns the planned windows with the alert sources and services each one covers.
  • Get Maintenance Window Returns one window with its period, scope, and notification settings.
  • Create Maintenance Window Schedules a window, which mutes the listed alert sources and marks the listed services as under maintenance for a fixed period, then undoes itself.
  • Update Maintenance Window Changes a window's period, scope, or notifications. Extending the end is how an overrunning change is covered.
  • Delete Maintenance Window Cancels a window. If it is currently open, the muted sources start alerting again immediately.

Heartbeat monitors

5
  • List Heartbeat Monitors Returns the heartbeat monitors with their interval, state, and integration key. A heartbeat is the only way to notice something that stopped.
  • Get Heartbeat Monitor Returns one monitor. Its state is the useful field: overdue means the thing that should have pinged did not, and unknown usually means it was created and never wired up.
  • Create Heartbeat Monitor Creates a monitor that raises an alert when nothing pings it inside its interval. The interval is in seconds, and it should sit comfortably longer than the job's real period.
  • Update Heartbeat Monitor Changes a monitor's name, interval, or routing. Widening the interval is the right fix for a job that legitimately got slower.
  • Delete Heartbeat Monitor Removes a monitor, after which nothing notices when the job it watched stops running.

Support hours

5
  • List Support Hours Returns the business-hours calendars that alert sources and flows branch on.
  • Get Support Hours Returns one calendar with its per-day windows and holiday exceptions.
  • Create Support Hours Defines a business-hours calendar for routing decisions.
  • Update Support Hours Changes a calendar's windows, timezone, or exceptions. The window and exception lists are replaced rather than merged.
  • Delete Support Hours Removes a calendar, and with it the business-hours branch of any rule that referred to it.

Deployment pipelines

5
  • List Deployment Pipelines Returns the pipelines with their integration type, key, and URL.
  • Get Deployment Pipeline Returns one pipeline with its key and any type-specific filters.
  • Create Deployment Pipeline Creates a pipeline so releases can be recorded against ilert's timeline.
  • Update Deployment Pipeline Changes a pipeline's name, key, or filters.
  • Delete Deployment Pipeline Removes a pipeline, after which jobs posting to its key start failing and the deploy correlation disappears.

Metrics

10
  • Ingest Metric Series Pushes time points into a metric so it can be charted on a status page. Keyed on the metric's ingestion key rather than its id.
  • List Metrics Returns the metrics with their aggregation and display settings.
  • Get Metric Returns one metric with its display settings and data source binding.
  • Create Metric Creates a metric that can be charted on a status page. A metric is fed either by a data source or by direct ingestion, not both.
  • Update Metric Changes a metric's display settings.
  • Delete Metric Removes a metric and its history, and status pages charting it lose the chart.
  • List Metric Data Sources Returns the monitoring connections metrics can be fed from.
  • Create Metric Data Source Registers a monitoring connection that metrics can pull from.
  • Update Metric Data Source Changes a data source's name or credentials, which is where a rotated key is applied.
  • Delete Metric Data Source Removes a data source, after which metrics bound to it stop receiving data.

Call flows

6
  • List Call Flows Returns the call flows in the account. A call flow is ilert's phone tree, answering a support number and routing the caller.
  • Get Call Flow Returns one call flow with its complete node tree, which is what an update has to be built from.
  • Create Call Flow Creates a phone-tree call flow from a nested node tree rather than a flat list.
  • Update Call Flow Replaces a call flow's name, language, number assignment, or node tree. Sending the root replaces the whole tree, so read it first.
  • Delete Call Flow Removes a call flow, after which any number assigned to it stops routing and callers to a published support line reach nothing.
  • List Call Flow Numbers Returns the phone numbers available to assign to call flows, with their country and current assignment.

Event flows

5
  • List Event Flows Returns the event flows in the account. An event flow reshapes and routes incoming events before they become alerts.
  • Get Event Flow Returns one event flow with its complete node tree.
  • Create Event Flow Creates an event flow from a nested node tree.
  • Update Event Flow Replaces an event flow's name or node tree. Sending the root replaces the whole tree.
  • Delete Event Flow Removes an event flow, after which events it was reshaping or suppressing go straight through unmodified.

Alert chat

8
  • List Chat Messages Returns the messages on an alert's channel, which is where responders coordinate inside ilert.
  • Create Chat Message Posts into an alert's chat channel, attributed to the key's user. How an agent hands a responder its findings in the place they are already looking.
  • Update Chat Message Edits a chat message. Only the author may edit their own.
  • Delete Chat Message Soft deletes a message. It remains in the list marked as deleted rather than disappearing.
  • List Thread Replies Returns the replies under a message, newest first.
  • Create Thread Reply Posts a reply under a message, which keeps a line of investigation together instead of scattering it through the channel.
  • Add Message Reaction Adds a reaction to a chat message on behalf of the authenticated user.
  • Remove Message Reaction Removes the authenticated user's own reaction. It cannot remove somebody else's.

Reports

3
  • Get Alert Report Returns alert metrics for a period, grouped as requested. Both ends of the period are required.
  • Get Alert Report Summary Returns a single summary of alert metrics for a period rather than the full series, which is the right shape for a digest.
  • Get API Key Usage Report Returns how much each API key has been used over a period, which answers both which key is about to hit its rate limit and which keys have gone unused and can be revoked.

Frequently Asked Questions

What can FlowRunner do with ilert?

FlowRunner agents can run Post Event, Post Deployment Event, and Ingest Metric Series in ilert, plus 160 more actions.

Does connecting ilert to FlowRunner require OAuth?

No. ilert connects to FlowRunner with an API key, no OAuth flow required.

Can ilert trigger a FlowRunner workflow automatically?

ilert doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with ilert

Free plan, no card required. Connect in minutes.