iLert
iLert is an incident response platform for managing alerts, on-call schedules, escalations, incidents, and status pages.
Verdict
Common use cases
- Check who's on call before escalating
- Pull overnight alert counts at standup
- Correlate customer tickets with active incidents
- Review escalation history for a critical alert
- List maintenance windows before deploying
Integration
- Vendor
- iLert
- Category
- other
- Auth
- API_KEY
- Tools
- 8
- Composio slug
ilert
Tools
- Get Alert
Get one iLert alert by its numeric ID, optionally expanding escalation rules, the next escalation user, or custom details.
- Get Current User
Return the authenticated iLert user, including identity, role, timezone, and active team context. Use this to verify who the API key represents before incident-response work.
- Get Incident
Get one iLert status incident by numeric ID, optionally including subscription state, affected teams, or history.
- List Alerts
List iLert alerts with optional state, source, escalation-policy, responder, and report-time filters. Returns one page and a continuation cursor.
- List Incidents
List iLert status incidents with optional lifecycle-state, affected-service, and report-time filters. Returns one page and a continuation cursor.
- List On Calls
Find who is on call for selected escalation policies, schedules, users, and a time window of at most three months. Returns one page and a continuation cursor.
- List Resources
List one incident-response resource catalog: services, teams, escalation policies, or maintenance windows. Use returned IDs as filters or references in alert, incident, and on-call tools.
- List Schedules
List iLert on-call schedules, optionally expanding current or next shifts and schedule definitions. Returns one page and a continuation cursor.
Setup
Setup guide
- 11. In Switchy, open Settings → Integrations and click Connect next to iLert. 2. Log into your iLert account and navigate to Settings → API Keys. 3. Generate a new API key with read scopes for Alerts, Incidents, Schedules, and On-Call; copy the key immediately. 4. Paste the key into Switchy's connection dialog and click Authorize. 5. Switchy will call Get Current User to confirm the key works and display your iLert username. 6. Open any Project, type '@iLert who is on call for the backend team?' and send; the MCP will query your schedules and return names and shift windows. 7. If the response is empty, verify your API key has access to the schedules you're querying.
What teammates see: by default, memories from iLert are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
On-Call Roster
@iLert who is on call right now across all schedules? Show me their names and when their shifts end.
Overnight Alert Summary
@iLert list all alerts reported since midnight UTC, grouped by severity. Include the alert source and current state.
Active Incident Check
@iLert show me all active incidents right now. For each one, include the affected services and when it was first reported.
Escalation History
@iLert get alert 482917 and expand the escalation policy and next escalation user. Show me the full timeline.
Upcoming Maintenance
@iLert list all maintenance windows scheduled for the next 7 days. Include the affected services and time ranges.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@ilert who's on call right now for our production escalation policy?
Based on the current on-call schedule, Sarah Chen is the primary responder for the Production Escalation policy until 6:00 PM UTC today. The secondary responder is Marcus Rodriguez, covering until tomorrow morning at 9:00 AM UTC. Both are members of the Platform Engineering team and have mobile notifications enabled.
This example requires the escalation-policy ID from a prior List Resources call. The on-call window is limited to three months, so historical queries beyond that range will fail. Useful for verifying coverage before planned maintenance or when triaging an active incident.
@ilert show me all critical alerts opened in the last 2 hours that haven't been acknowledged yet
Three critical alerts remain unacknowledged: Alert #8472 from the API Gateway service (reported 47 minutes ago, escalated to the Platform team), Alert #8469 from the Payment Processor (reported 1 hour 12 minutes ago, escalated to Backend team), and Alert #8465 from the Database cluster (reported 1 hour 58 minutes ago, escalated to Infrastructure team). All three are currently in PENDING state and have active escalation policies running.
This read-heavy query demonstrates filtering by state, priority, and time window. The List Alerts tool returns paginated results, so if your environment generates high alert volume, the first page may not capture everything. Pair this with Get Alert to expand escalation rules or custom details for triage.
@ilert summarize the last 5 status incidents affecting our API service and draft a brief internal update
The last five incidents affecting the API service span 14 days: two brief latency spikes (resolved within 30 minutes each), one certificate renewal issue (resolved in 2 hours), one upstream dependency timeout (resolved in 45 minutes), and one planned maintenance window (4 hours). Draft update: 'API service experienced four unplanned incidents over the past two weeks, all resolved within SLA. Primary causes were external dependencies and certificate management. Monitoring coverage expanded to catch cert expiry earlier.'
This synthesis example chains List Incidents (filtered by affected service) with the AI's summarization. The MCP returns structured incident data—state, duration, affected teams—but the narrative framing comes from the model. Useful for post-incident reviews or stakeholder updates when you need context beyond raw ticket lists.
Use-case deep-dives
When iLert MCP helps small teams close the loop faster
A 6-person SRE team runs a weekly incident review in Slack. The facilitator pulls the last seven days of resolved alerts with List Alerts, filters by escalation policy, then uses Get Alert to expand custom details for the three that escalated twice. The team pastes summaries into a thread and tags responders. This MCP works because iLert's alert history is the single source of truth and the team reviews fewer than 20 incidents a week. If your org runs 100+ alerts daily or needs cross-tool correlation with PagerDuty or Datadog, you'll spend more time reconciling IDs than writing retros. For small teams on iLert-only stacks, this cuts retro prep from 30 minutes to under five.
Why this MCP beats manual schedule checks for support rotations
A 4-person customer success team rotates weekend on-call coverage across two schedules. Every Friday afternoon, the outgoing responder uses List On Calls to confirm who's live for the next 72 hours, then drops a Slack message with the name and escalation policy. The MCP returns current and next shifts in one call, so there's no calendar-hopping or timezone math. This scenario wins because the team checks schedules 50+ times a year and iLert's API is faster than opening the web UI. If your rotation changes hourly or spans more than three schedules, the three-month window and pagination become friction. For weekly or daily handoffs with predictable schedules, this MCP turns a two-minute task into a ten-second Slack command.
When iLert MCP is the wrong tool for executive dashboards
A VP of Engineering wants a quarterly slide deck showing incident volume by service, mean time to acknowledge, and repeat offenders. The analyst tries List Incidents with report-time filters, then realizes the MCP returns one page at a time and doesn't aggregate metrics. After three pagination loops and manual spreadsheet pivots, the task takes two hours. This MCP isn't built for bulk export or analytics—it's designed for real-time lookup during active incidents. If you need historical trends or cross-quarter comparisons, export iLert data to a BI tool or use their reporting API directly. Use this MCP when you're triaging live alerts in Slack, not when you're building executive decks.
Frequently asked
What does the iLert MCP do in Switchy?
It pulls alert and incident data from your iLert account so AI agents can check who's on call, look up open alerts, and read status-page incidents without leaving the conversation. You can filter by escalation policy, service, or time window. The MCP doesn't create or acknowledge alerts—it's read-only visibility into your incident-response state.
Do I need admin access to connect iLert?
You need an iLert API key with read permissions on alerts, incidents, schedules, and resources. Admin access isn't required, but the key must belong to a user who can see the escalation policies and teams you want to query. Use the Get Current User tool to confirm which account the key represents before sharing it with your team.
Can the iLert MCP acknowledge or resolve alerts?
No. The eight tools are all read-only: list alerts, get incident details, check who's on call, and fetch resource catalogs. If you need to acknowledge or escalate an alert, you still open iLert directly or use their API. This MCP is for surfacing incident context to AI agents, not replacing your on-call workflow.
Why use this instead of just opening iLert?
When an agent is already troubleshooting a deployment or customer issue in Switchy, it can check who's on call or pull the last three alerts without you context-switching to the iLert dashboard. You still go to iLert for ack/resolve actions, but the MCP saves the lookup step when you're mid-conversation.
Who on the team should connect the iLert MCP?
Whoever owns your on-call rotation or incident-response process. The API key will see every alert and schedule that user can see, so choose someone with appropriate read access across the teams you want agents to query. One connection covers the whole Switchy workspace—you don't need separate keys per person.