Revenue stops with the system
If customers transact through your software, downtime is directly lost income — and it lands hardest during exactly the busy periods that generate the most.
04 How we build
The day it goes down is the day it matters.
Outages rarely happen at convenient times. Availability is the difference between a problem your engineers handle quietly and a problem your customers announce for you.
Start a projectFailure is normal. Outages are optional.
Things fail. Hardware dies, networks partition, third-party providers have bad days, and code paths nobody anticipated get exercised. No amount of care makes failure impossible — availability is not about preventing it, it is about deciding what happens next.
In a poorly designed system, any single failure takes down everything, because every part depends on every other part being healthy. In a well-designed one, failure is contained: the affected piece restarts or is routed around, and the rest of the system carries on serving customers who never learn anything was wrong.
The other half is knowing. Plenty of teams find out their system is down when a customer tells them. Monitoring and alerting from day one changes that — degradation gets caught while it is still small, and you hear about it from us with a fix already underway.
How to tell if this is your problem
Every project starts with a scoping call- ↳ You have found out about downtime from a customer
- ↳ One failing component takes the whole system with it
- ↳ Deploying requires taking the site offline
- ↳ There is no alerting, or the alerts are ignored
- ↳ Recovery depends on one person being available
- ↳ Nobody knows how long a restore from backup would take
How we deliver it
- OTP supervision
- When a process crashes, its supervisor restarts it in milliseconds. The rest of the system never notices.
- Oban
- Background jobs are stored in Postgres inside your transaction. A crash mid-payment means the job retries, not that it vanishes.
- Monitoring from day one
- You hear about degradation from us, with a fix underway — not from an angry customer.
What it costs to ignore
Reputation costs outlast the outage
The incident lasts an hour. The impression that your product is unreliable lasts much longer, and it spreads through exactly the channels you cannot control.
Recovery without a plan takes far longer
Teams that have never rehearsed a restore discover during the outage that the backup was incomplete, or that nobody has the credentials. Improvising turns minutes into hours.
Silent failures are the worst kind
Without monitoring, degradation goes unnoticed until it is severe. Slow-building problems — a filling disk, a leaking connection pool — are cheap to fix early and expensive once they take the system down.
Questions we get asked
- Do we need 99.99% uptime?
- Almost certainly not, and chasing it is expensive. What matters is matching the target to the business: a system taking payments around the clock has different needs from an internal tool used in office hours. We would rather set a target you actually need than sell you a number.
- What happens when something does break?
- Supervised components restart automatically in milliseconds, so most failures are absorbed without anyone noticing. For anything larger, alerting reaches us directly — you hear from us with a fix in progress, not from a customer.
- Does high availability mean paying for duplicate infrastructure?
- Not necessarily. A lot of resilience comes from design rather than hardware: contained failures, retry-safe background jobs, and a caching layer in front of your application. Redundancy helps, but it is not the first or cheapest lever.
- Can you deploy without taking the site down?
- Yes. Releases roll out gradually with the previous version still serving until the new one is healthy, and rolling back is a normal operation rather than an emergency. Deployment should never require a maintenance window.
- How do you know the system is healthy?
- Metrics, logs, and error tracking configured from the start, with alerts on the things that predict a problem rather than just confirm one. When something breaks, the question is where — not whether.
The day it goes down is the day it matters.
Tell us where it hurts. A short call, an honest answer on whether we are the right team, and a scope you can budget against.
Start a project hello@elixiria.ma