Backend downtime during a demo

I had a demo ruined by backend downtime.

I was demoing my Little Black Book app — a React and Express project for storing, adding, amending, deleting, sharing etc. cocktail recipes. The frontend was loading fine, but when I tried to fetch the list of drinks from the API, the request just froze. No response. No errors. Just dead air.

The worst part was I knew this happens. Before the demo, I’d even prepped for it. I opened the app, clicked around, made sure the backend on Render was awake. But the demo came late in the conversation, and Render’s free tier 15-minute inactivity limit quietly kicked in while we were talking.

By the time I actually showed the app, the backend had gone to sleep. So the first request during the demo… just didn’t return.

my demo was a long awkward fumbling around, refreshing and some fast talking.

---

The problem

Render shuts down free services after 15 minutes of inactivity.
It’s a free tier.
But if your frontend and backend are hosted separately (like mine, with Firebase for the frontend), you run into cold starts that feel like total failures during a live demo.

Especially if:

• You rely on real-time API responses
• You’re in an interview or trying to showcase your work

---

What I did differently in VISOR

After that demo, I needed to figure out how to never let that happen again.

When I started building VISOR — my photography platform for sharing film simulations and Lightroom presets — I baked in a fix from day one.

---

The fix: a simple health check + UptimeRobot

I added a /health endpoint to the Express backend:

  app.get("/health", (req, res) => {
    res.status(200).json({
      status: "healthy",
      environment: NODE_ENV,
      timestamp: new Date().toISOString(),
    });
  });

`

This gives me a simple, safe endpoint that uptime monitors can ping.

Then I set up UptimeRobot to hit it every 5 minutes:

• Monitor Type: HTTP(s)
• URL: https://visor-backend.onrender.com/health
• Interval: every 5 minutes

That’s it — the backend stays alive, even when I haven’t touched it in days/weeks/months.

---

When things go down: Render incidents

After adding UptimeRobot to VISOR, I started getting real insights into what was happening when the backend became unavailable.

In this case, Render returned multiple 503 Service Unavailable errors from different locations. This usually means one of two things:

• The server was put to sleep after 15 minutes of inactivity (standard for free tiers)
• The service was cold-starting but hadn’t run quickly enough to respond - timed out basically

Because I’d set up a health check monitor in UptimeRobot, it detected the outage, logged the exact start time, and alerted me via email.

Then, as soon as the next ping got a valid response from /health, it marked the issue as resolved.

This kind of insight is gold when you're debugging uptime issues, especially with free platforms. Without it, I'd just see random timeouts in the frontend with no clear reason.

---

So how does UptimeRobot actually help?

By default, Render won’t keep your app running 24/7 unless it’s on a paid plan. That means your backend can fall asleep between uses — especially overnight or during development pauses.

What UptimeRobot does is send regular HTTP requests to your app’s /health endpoint. That traffic is enough to keep the backend alive — or at the very least, wake it up before you or your users need it.

So instead of cold starts during live demos or delays in the browser, everything’s ready to respond.

It's a free fix for a free hosting, for cheapskates like me.

---

Simple lessons learned

• Add a /health route to your backend — it's actually so simple and will save you a lifetime of embarrassment
• Use UptimeRobot to prevent Render cold starts before demos or testing.
• Free hosting is great, but you’ve got to understand it's free and limited.

---