Why I built Faultline
I'm Chris Collareta, and I build Faultline. It exists because the failures that hurt most never touch a public endpoint, and the tools that page you can't see them.
What problem does Faultline solve?
The ones that become a support ticket before you see a red light: the nightly backup that silently stopped, the queue worker that wedged at 2am, the ECS task crash-looping since the last deploy. Uptime checkers watch a URL returning 200, so they miss all of those.
The other half was the paging. Most tools fire on the first failed check, so a network blip wakes someone up, and when something really breaks there is no runbook and no context. I wanted one tool that owns the whole loop, from detection to post-mortem, without wiring two or three paid products together.
What is different about it?
- It sees background work. Heartbeats catch cron jobs and workers that stop, and Docker and ECS monitors watch containers directly.
- Your AI agent can work incidents, with your approval. Claude can diagnose an incident over MCP, but a person says yes before any runbook runs.
- Flat pricing. One price per plan, not per user. See pricing.
What does it not do?
It is not an APM: no distributed tracing and no log aggregation. If you need those, Datadog or New Relic is the right tool. Self-hosting and SOC 2 Type II are on the roadmap, not shipped.
How can I check that it works?
Faultline monitors itself in public. Its own status page, status.fltln.io, has run on Faultline since . How customer data is isolated and what reaches the AI model is documented in Security and data handling.
How do I reach you?
Email hello@fltln.io, or find Faultline on LinkedIn. Everything I have written about Faultline is on my author page.