What happened

Our monitoring flagged lost connectivity on a small number of servers. There was no graceful degradation and no warning signs in the preceding metrics. The machines simply stopped responding.

The first hour went into diagnosis. Remote access was gone, so we were working through out-of-band management and datacenter remote hands rather than a terminal. Most of that hour went into narrowing the fault down to something a technician could physically act on.

We identified faulty RAM on the primary affected machine. Remote hands swapped the modules and we brought the servers back up.

The fault persisted. The RAM was genuinely bad, but it wasn’t the whole story. Further diagnosis pointed to the mainboard.

Remote hands replaced the board. After the wait for parts and the physical work, the affected servers came back up and have been stable since.

Separately, the other machines caught up in this incident failed for a different reason: power supply units. Two unrelated hardware faults in the same window.

One clarification worth making, because we’d rather be precise than dramatic: the largest of the affected machines was not our largest server. This was not a failure at the core of our platform.

What we took away from it

We held a post-incident review once the dust settled.

The conclusion wasn’t that we’d been careless with hardware. Hardware fails. RAM goes bad, boards go bad, PSUs go bad. That happens at every provider, at every scale, and no procurement policy makes it stop.

The real finding was this: a single component failure should never be able to take a customer’s service offline. The hardware fault wasn’t the incident. The lack of anywhere for those workloads to go was the incident.

So we stopped asking how to avoid bad hardware and started asking how to make bad hardware irrelevant.

Standby instances

We looked at the existing options first. Most high-availability tooling assumes an orchestration layer, a load-balancer tier, or a shared-storage setup that didn’t map cleanly onto how our platform is built today. So we designed something that fits our stack.

We call it a standby instance. If you know the pattern as warm standby or active-passive failover, that’s exactly the family it belongs to. We’re not claiming to have invented failover. What’s new is that we’re building it in at the platform level, so you get it without architecting for it yourself.

A standby instance is a full replica of your running service, but instead of sitting cold on disk as a backup archive, it is live and running, on separate hardware, with no DNS pointing at it. It’s warm, it’s current, and it’s invisible until it’s needed.

How it works

Say you’re running three services on CranL: a frontend, a backend, and a database.

Each one has a standby replica running on a different physical host. Under normal conditions your traffic never touches them. They exist purely to be ready.

If the hardware underneath your primary instances fails, we shift the network configuration to the standbys. In our current implementation that cutover takes under two minutes, which is the time needed to make the routing change on our side.

From the outside, most users won’t notice anything beyond a brief spike in latency. In many cases, neither will your monitoring.

What this doesn’t do

We’d rather set expectations correctly than oversell this.

• We are not promising 100% uptime. Anyone who does is either rounding generously or hasn’t had a bad week yet. What we’re promising is that hardware failure stops being a several-hour event and becomes a several-minute one.

• Cutover is currently operator-triggered. Detection is automated, but the failover decision still passes through a human. Automating it is on the roadmap, and we’d rather ship the manual version now than promise the automatic one later.

• DNS caching is real. Some clients and resolvers will hold a stale record past our TTL. We’ve tuned TTLs down accordingly, but a small tail of traffic may take longer to converge than the two-minute figure above.

• Database standbys carry replication lag. For most workloads it’s negligible. For write-heavy ones it isn’t nothing, and we’ll publish per-tier specifics as we roll this out.

Finally

To everyone whose service was affected: we’re sorry. Downtime you didn’t cause and couldn’t fix is genuinely frustrating, and the hours you spent waiting on us is not the experience we want to be known for.

Standby instances start rolling out shortly. If you want to talk through what this means for your specific setup, get in touch and we’ll walk you through it.

We’ll keep writing these, the good launches and the bad weeks both.

The CranL Team

ليش نستخدم سوبابيس ؟

سوبابيس نستخدمها في مجال التطبيقات بشكل أساسي لأنها توفر لنا بيئة قواعد بيانات بوستجري ونظام تخزين ملفات يسهل الكثير على المطورين…

وبعد ماتعرفنا على سوبابيس

السؤال الأهم…

كرانل منصة وافية , كما عهدناها دوماً

منصة تدعم الوطن العربي ومنطقة الشرق الأوسط بشكل أساسي , على عكس أغلب مزودي الخدمة اللي يكون تركيزهم على قارة أمريكا الشمالية أو منطقة غرب أوروبا , كما أن اشتراك كرانل ثابت مقابل الخدمات المقدمة لك

كيف أنقل لسوبابيس كرانل ؟

سجل حساب

من هنا

سجل في أحد الخطط الموجودة في الموقع

الخطط الموجودة

ويُفضل الخطة الإحترافية أو خطة المؤسسات كونها تحتوي على ميزات أسطورية جداً مثل :

• CranL Emails : خدمة بريد الكتروني توفر عليك العناء والتعب وتخدمك بأكبر قدر ممكن

• CranL Sandboxes : صناديق الرمل من كرانل خدمة تتيح لك إنشاء بيئات تشغيل آمنة تستضيف فيها مشاريعك ونماذج الذكاء الاصطناعي العصرية الخاصة بك بدون توقف مع خدمة فورية

Useful links

• Cranl Docs
• Justfuckingusecranl.com

Why use CranL BaaS?

• Deploy your backend in any region you choose

• Full data residency

• Fully managed by CranL 😎

• Included in your plan, with no extra fees

• Made and hosted in Saudi Arabia 🇸🇦 and supporting many other regions (Mainly MENA region) .

Start now, and deploy your backend within CranL!

Why use CranL Emails?

• API access for automations and systems

• Made and hosted in Saudi Arabia 🇸🇦 and supporting many other regions (Mainly MENA region) 😎.

• No extra fees, Can be used with your main subscription plan.

• Broadcasts

• Dealing with webhooks

Start now, and send emails within CranL!

Railway

• Plan : Hobby
• Billing model : Usage-based ¯_(ツ)_/¯
• Hobby base fee : $5.00
• App compute (512MB / 0.5 vCPU) : $5 – $8
• Postgres (1 GB RAM) : $5 – $10
• CDN and also S3 storage not included :(

But…

Cranl.com

• Plan : Pro
• Billing model : Flat-price
• More flexiable
• Github deploy supported
• Sandboxes supported
• CLI + REST API + MCP
• Traffic analytics supported
• SSL supported
• Great DDoS Protection and Security
• Primarly based in MENA region (KSA-EGY-UAE-and coming soon more…)
• Also supporting India - Europe - USA
• Supporting Odoo , Wordpress , Mattermost and Openclaw
• Can be supporting Static-web generators frameworks such as : Jekyll , Hugo and Quarto ;-) .

Same app. Same DB. What you actually pay. Railway bills by the minute. Your invoice is different every month. CranL doesn’t.

Comparsion between cranl.com versus others

Save your money and using cranl.com …

What is CranL Sandbox ?

Cranl Sandbox is place where you can deploy and host your AI agent directly using your GitHub repo .

First Push your code into the repository , then connect the repo with CranL and Deploy it for make an isolated machine that you can control , That’s all.

What you get when using Cranl.com

The cloud VM that feels like your local machine. Everything you’d wire up yourself — pre-wired. Ubuntu 24.04 LTS, always up to date.

what you’ll find here

• Engineering — architecture decisions, performance investigations, real benchmarks
• Infrastructure — how we run our global PaaS: deployments, databases, CDN, reliability
• Product — how we translate user feedback into technical requirements and ship without chaos
• Postmortems — when things go wrong (they do), we write up what happened and what changed

Give your agents a real machine to work on ¯_(ツ)_/¯

Most agent frameworks run on serverless functions — environments that sleep, time out, and share nothing. A Cranl sandbox is different: a persistent VM your agent owns end to end.

what cranl is

CranL is a PaaS that makes deployment easy and cost-effective. Deploy applications, databases, and templates in seconds — with global infrastructure, GitHub integration, free CDN, SSL, and DDoS protection included. We’re building what we wished existed when we were deploying our own projects.

why we’re writing

Three reasons.

Writing forces clarity. The act of writing a blog post about a technical decision is the best way we know to stress-test that decision. You can’t hide behind “it’s complicated” when you’re explaining it to someone without your context.

It compounds. A detailed post about a problem we solved saves future teammates hours of archaeology through commit history. It may also save you the same hours if you hit the same problem.

Good engineers find good writing. The people we most want to work with tend to produce or consume substantive technical content. This blog is partly a signal.

what you’ll find here

• Engineering — architecture decisions, performance investigations, real benchmarks
• Infrastructure — how we run our global PaaS: deployments, databases, CDN, reliability
• Product — how we translate user feedback into technical requirements and ship without chaos
• Postmortems — when things go wrong (they do), we write up what happened and what changed

how this blog is built

The blog lives at blog.cranl.com and is fully static — generated with Quarto and deployed via CranL itself. No backend, no database, no auth wall. The CSS design tokens are shared with the main site so the two feel like one product.

Techinal Writer and Data Scientist 0xSaad