The monitoring platform your AI agent can operate.
Faultline watches the infrastructure other monitors can't see - cron jobs, queues, Docker, ECS - and exposes all of it through an MCP server. Claude can check health, diagnose incidents, and run the fix. With your approval.
5 monitors free. No card. Cancel anytime.
Monitoring didn't get smarter. It got louder.
Most tools watch public HTTP endpoints and page you when something's already on fire. Your background jobs, queue workers, and cron tasks stay invisible until a downstream failure becomes a customer problem. And when the page comes at 3am, every "AI-powered" incumbent hands you the same thing: a graph and a guess. Nothing you already use, Claude, your CLI, your Slack, can actually do anything about it.
- 11:42 PMBackground job stops processing
- 11:43 PMNo alert fired, not monitored
- 2:17 AMSupport ticket: "orders not going through"
- 2:18 AMOn-call woken up with no runbook, no context
- 3:04 AMResolved after 82 minutes of downtime
82 minutes. One angry customer. No idea it was coming.
- 11:42 PMJob stops pushing its heartbeat
- 11:43 PMFaultline detects the missed check-in
- 11:44 PMIncident opened, runbook attached, L1 paged
- 11:51 PMService restarted via runbook, resolved
- ·No customer impact. 9 minutes, start to finish.
Detected, paged, and remediated before anyone noticed.
One agent loop. Terminal, Slack, and Claude.
Faultline ships an MCP server, a CLI, and a Slack bot over one agent loop - so Claude can diagnose an incident and run the fix. Every fix waits for your yes. That's a stance, not a limitation.
Datadog, Grafana, and the AI-SRE tools now ship an MCP server that lets an agent read your telemetry. Faultline's MCP can act on it - run the runbook, verify recovery, escalate if it didn't hold.
Ask in plain language, from anywhere
Point Claude Code, Claude Desktop, or any MCP agent at Faultline and it can check service health, inspect incidents, and see who's on call. Same agent loop in the terminal (faultline ask) and in Slack (@Faultline).
$ faultline ask "why is checkout-api degraded?"
# reading timeline, recent checks, runbooks…
Latency 6× baseline since 14:02 - matches IN-2841
(connection-pool exhaustion).
Suggested fix: restart-api-pool
Incidents that write themselves up
Every incident summarizes itself - what happened, blast radius, likely cause - and drafts a blameless post-mortem on resolve. MTTA and MTTR are computed in code, so the numbers are exact; only the prose is drafted. Every resolved incident becomes precedent the next diagnosis can cite.
What happened - checkout-api response times rose 6× over 18 min before failing.
Blast radius - 1 service; payments-api unaffected.
The y/N gate is the differentiator, not the caveat
Autonomous remediation is how the tool meant to prevent a 3am outage causes one. So diagnosis recommends; it never executes. Running a runbook is a separate, explicit approval - a y/N in the CLI, an admin action in the dashboard. A hallucinated runbook ID is validated server-side and downgraded to 'escalate,' so a foreign or invented runbook can never run.
diagnose → run_runbook restart-api-pool ?
Run this runbook? [y/N] y
✓ executing · verifying recovery in 120s
# still DOWN → escalates to a human
From raw alert to closed incident, without waking anyone.
Three capabilities that turn raw alerts into a calm, automated incident response.
No more 3am false alarms
Most monitors page you on the first failed check. Faultline uses configurable thresholds, where 2 failures means DEGRADED and 3 means DOWN, so transient blips don't wake your team. You define what 'broken' actually means for each service.
Thresholds are per-service. You decide what counts as broken.
The playbook runs itself
Attach runbooks to services before incidents happen. When a check fails, Faultline can restart your ECS service, call an HTTP endpoint, notify Slack, and update the incident, all before anyone picks up their phone.
$ runbook: restart-job-processor
✓ ecs:update-service --force-new-deployment
✓ http:post /internal/cache/flush
✓ slack:notify #incidents
✓ incident:resolve IN-2941
done in 6.2s, no human paged
Monitor what HTTP checks can't see
Use faultline-cli to push heartbeat events from background jobs, queue processors, and scheduled tasks. If a job stops reporting in, Faultline opens an incident automatically. External uptime checks never catch silent internal failures.
# from inside your worker
faultline-cli push \
--service job-processor \
--status ok --every 60s
# miss a heartbeat → incident opens automatically
Monitoring your first service takes five minutes.
No agents to babysit, no YAML sprawl. Add a service and you're live.
Add a service
Paste a URL, connect Docker/ECS, or integrate via CLI. Takes 60 seconds.
Set thresholds
Define what degraded and down mean for this service. Configure retry logic and check intervals.
Attach an escalation policy
Who gets paged, in what order, with how much delay. Add a runbook if you have one.
Sleep better
Faultline handles detection, escalation, and remediation. You get the full incident timeline and audit log after the fact.
Start free. Upgrade when on-call gets serious.
No credit card to start. Every plan includes the full real-time dashboard.
Free
Side projects and solo stacks.
- 5 monitors
- 2 team members
- 60s checks
- 7-day retention
Pro
On-call teams who need real escalation, not just email.
- 50 monitors
- 10 team members
- 30s checks
- Runbooks + escalation
Growth
High-volume checks, longer retention, more seats.
- 150 monitors
- 25 team members
- 15s checks
- 180-day retention
Enterprise
Custom controls, unlimited scale.
- Unlimited everything
- Custom intervals
- 1-year retention
- Priority support
All plans include a real-time WebSocket dashboard, audit logging, Slack / PagerDuty / Webhook integrations, and SSL certificate monitoring.
Need more monitors? Pro overages are $1.50/monitor/mo.
Honest comparisons, including where they win.
Datadog is better at APM depth. PagerDuty has more integrations. We'll tell you exactly where, and where Faultline replaces both for a tenth of the bill.
Faultline vs Better Stack
Monitoring and incidents in one product. An honest look at where each one wins.
Read the comparisonFaultline vs PagerDuty
Paging plus the detection layer PagerDuty doesn't do itself.
Read the comparisonOpsgenie alternative
Replace on-call and escalation before the April 2027 Opsgenie shutdown.
Read the comparisonFaultline vs Datadog
The detection-and-incident loop without the per-host observability bill.
Read the comparisonFaultline vs AI-SRE agents
NeuBird and the AI-SRE tools reason over your observability stack. Faultline is the stack.
Read the comparisonUptimeRobot alternative
When a ping check stops being enough and you need the incident response.
Read the comparisonHealthchecks.io alternative
Cron heartbeats plus full monitoring and an incident loop around them.
Read the comparisonQuestions a skeptical SRE would ask.
How is this different from Pingdom or Better Uptime?
Those tools check external HTTP endpoints. Faultline also monitors internal processes (background jobs, queues, cron tasks) via event ingestion, has multi-level escalation policies, and runs automated remediation runbooks. It's not just uptime; it's incident response end to end.
What happens when I exceed my monitor limit?
You'll get a warning in the dashboard. On paid plans, overages are billed at the per-monitor rate for your tier. On Free, new monitors are blocked until you upgrade or remove existing ones.
Can I self-host?
Not yet. Faultline is a fully managed cloud service today, and self-hosting in your own VPC is on the roadmap for the Enterprise tier. Your check data stays in your organization and is never shared.
Does it work with Docker and ECS out of the box?
Yes. You can connect Docker containers and AWS ECS services directly from the dashboard. Faultline polls container health and can restart services via runbook actions automatically.
How quickly can I get set up?
Most teams are monitoring their first service within 5 minutes. Add a URL, set a threshold, and you're live. Escalation policies and runbooks take a bit longer but are optional to start.
Your next incident is already scheduled. You just don't know when.
Set up your first monitor in under two minutes. When it fires, let Claude handle it.
Questions? Reach out.