Use Case

Uptime Monitoring for Indie Hackers: The 2026 Free Stack

May 12, 202611 min read

TL;DR: The free monitoring stack indie hackers leaned on in 2022 has mostly aged out. UptimeRobot banned commercial use in November 2024. Fly.io pulled new-customer free plans in October 2024. Render free services still spin down at 15 minutes, and a monitor pinging them every 5 minutes is not a fix. The realistic 2026 setup for a $0 to $5 per month side project is four monitors on the Velprove free plan: one HTTP monitor with a body assertion, one multi-step API monitor on the auth flow, one browser login monitor on the actual sign-in (free on Velprove, gated to $36 per month on Site24x7 and $64 per month on Checkly), and a public status page. That covers what HTTP alone misses without pretending you have upgraded off the free tier.

What broke in the indie-hacker free stack since 2022

From 2022 free-tier abundance to 2026 paid-by-default

The 2022 indie monitoring playbook was simple. Deploy on a free-tier host (Heroku free, Fly.io free, Railway free), point UptimeRobot at it, get an email when it falls over. That stack has mostly aged out. Heroku free went away in November 2022. Fly.io stopped onboarding new free accounts in October 2024. The Fly.io pricing page now reads verbatim: "Fly.io no longer offers plans to new customers." A new account today starts at roughly $0.0028 per hour for the cheapest always-on machine, or about $2 per month per VM.

Railway followed a similar arc. There is no permanent free tier anymore. New trial accounts get a one-time $5 credit that expires in 30 days, and after that the cheapest plan is the $5 per month Hobby plan, which includes $5 of resource usage and bills the delta. Railway's docs are explicit about both numbers. UptimeRobot, the default free monitoring service for the entire 2018 to 2024 era, changed its terms in late 2024 so the free plan no longer covers commercial use. We covered the full picture in UptimeRobot's free plan banned commercial use in November 2024.

What that means for your $5 per month side project today

The survivors are Vercel Hobby, Render free, Cloudflare Pages, and a few static-only options like GitHub Pages. Each of them comes with a different gotcha that a 2022 reader did not have to think about. Vercel Hobby is explicitly excluded from any uptime SLA and its runtime logs are kept for 1 hour. Render free services spin down after 15 minutes of inactivity. The honest framing for a side project in 2026 is that "free" is conditional in ways it was not three years ago, and your monitoring choices have to be made knowing which tier you are actually on.

Render free spin-down: monitoring is not a keep-alive ping

The 750 free instance hours math

Render's docs are direct about the spin-down behavior: "Render spins down a Free web service that goes 15 minutes without receiving any inbound traffic." The first request after spin-down takes "about one minute" to complete. The free workspace gets "750 Free instance hours to each workspace per calendar month."

Do the arithmetic. A service kept awake 24 hours a day for 30 days uses 24 times 30, or 720 hours. That fits inside the 750 cap, but only just, and only if you have one service. Two services on keep-alive pings exceed the cap and the second one stops accepting traffic for the rest of the month. A third service is impossible to keep awake on the free plan at all.

Why "ping it every 5 minutes" is a hosting decision, not a monitoring decision

The instinct from the 2018 playbook is to point UptimeRobot or any external pinger at the Render URL every 5 minutes and treat that as the fix. Pinging every 5 minutes is not the fix. Any pinger that keeps the service from sleeping for the full 720 hours of a 30-day month is using your 750-hour cap as a keep-alive budget instead of an honest measure of real usage. With one such service you have a 30-hour buffer; with two services you exceed the cap and the second service stops responding partway through the month. If your goal is to keep the service awake, the right move is to upgrade to Render's $7 per month Starter web service, which does not spin down. The wrong move is to set your monitor frequency to defeat the platform behavior the host intentionally includes. The monitor is for telling you when the site is broken, not for keeping it warm. Those are two different jobs and only one of them is the monitor's.

The four failure modes that matter on a side project

Once you have decided what tier you are on and how much warmth you can afford to pay for, the question is what to actually monitor. Four failure modes cover most of the territory for a small side project.

The platform itself sleeps or archives the function. Render free spins down at 15 minutes. Vercel preview functions get archived after 48 hours of no invocation. Railway with serverless mode enabled sleeps services after 10 minutes. Catching this means an HTTP monitor on the production URL, but with the cold-start time built into your timeout budget so the wake-up does not get logged as an outage.
The auth flow breaks while the marketing page stays up. This is the load-bearing one and the reason a real-browser monitor exists. Your homepage returns 200, the SSL cert is fine, the favicon loads, and the login form looks identical to yesterday. Then a user types their password, gets bounced back to the login page with no error message, and silently leaves. 200 OK is not the success condition. The fix is a browser login monitor that uses a real browser, fills the form with a low-privilege test account, and verifies the post-login screen actually rendered.
A third-party API your side project depends on returns degraded responses. Stripe, Supabase, or Postmark returns a slow or partial response, and your application code propagates it as a 200. The fix is asserting on the response body of the calls you depend on, not just on the status code at your own URL.
Your domain or SSL silently expires. You set up the side project with a credit card you have since canceled. The domain renewal fails. The Let's Encrypt cert tries to renew through a service that no longer has billing on file. The site goes dark on a Tuesday afternoon and you find out from a tweet. SSL certificate monitoring is included on the Velprove free plan and catches this without any extra setup.

A 4-monitor setup that fits the Velprove free plan

Four monitors. The Velprove free plan allows 10, so you have 6 left for staging, webhook receivers, and whatever your stack actually depends on. The four below are the ones every side project should run.

Velprove monitor list view for an indie hacker's free plan with four monitors visible: an HTTP monitor on the production website, an API monitor on the auth flow, a Multi-Step monitor on the login token flow, and a Browser Login monitor on the actual sign-in page, each one assigned to a different global region. — The four-monitor side-project setup on the Velprove free plan: HTTP on the production URL, API on the health endpoint, Multi-Step on the login token flow, and Browser Login that drives a real browser through the actual sign-in. Each monitor catches a failure mode the others cannot see.

Monitor 1: HTTP monitor on the production URL with body assertion

The cheapest, fastest monitor to set up. Point an HTTP check at your production URL on a 5-minute interval (the free plan's floor) from any of the 5 global regions (North America, Europe, UK, Asia, or Oceania). Pick the region closest to your users for the lowest probe latency. The non-obvious part is the body assertion. Do not just check for a 200 status code. Assert that the response body contains a string that only appears when the page rendered correctly: a date string, the build SHA, a key marketing headline. A cached error page from the CDN often returns 200 with a generic error in the body, and the assertion is what catches that.

Velprove new-monitor wizard at the Verify step (Success Conditions) for an HTTP monitor on a production URL, showing two conditions: the default Status Code Equals 200, and a Body Contains assertion with the value Sign in that proves the rendered HTML actually contains the expected page content rather than a cached error placeholder. — Step 2 of the HTTP monitor wizard: a Body Contains assertion on the literal string 'Sign in'. The first row is the default Status Code Equals 200; the second is the assertion that catches a cached-error 200.

Monitor 2: Multi-step API monitor on the login or token flow

The Velprove free plan includes multi-step API monitors with up to 3 steps. That fits the standard auth flow exactly: POST to the login endpoint and extract the token, GET a protected resource using the token, assert that the protected response contains the expected user identifier. Use a low-privilege test account that you created specifically for monitoring, never your own admin credentials and never a real customer's account. The full walkthrough is in the multi-step API monitoring walkthrough.

Velprove multi-step monitor configuration with all three steps expanded: Step 1 POST to a login endpoint with a token extraction rule, Step 2 GET to a protected resource with an Authorization Bearer header, Step 3 GET to a user-identifier endpoint with a response-body assertion. A 'Step limit reached (3/3). Upgrade for more steps' banner is visible at the bottom. — The 3-step auth flow on the free plan: POST to login and save the token, GET a protected resource with the token in the Authorization header, GET the user id and assert the response body matches. This is the multi-step monitor that catches an auth flow breaking even when the homepage stays up.

Monitor 3: Browser login monitor on the actual sign-in

The Velprove free plan includes 1 browser login monitor on a 15-minute interval. The monitor opens a real browser, navigates to your login page, fills in the credentials of your low-privilege test account, clicks submit, and verifies the post-login page rendered as expected. By default the success check is that the URL changed from the login page; you can also opt into checking that a specific text or element appears on the post-login screen. This is the monitor that catches the silent failures HTTP cannot see: a redirect loop, a session cookie that gets set but is immediately invalid, JavaScript that fails to render the dashboard. Browser login monitors are the single biggest reason an HTTP-only setup misses real outages.

Velprove new-monitor wizard at the Configure Browser Login Monitor step, with the Login Page URL filled with the herokuapp test login URL, the Username and Password fields populated with the herokuapp test credentials, and the Customize Detection panel expanded to show the Success verification dropdown set to Page contains text with the value Logout, the post-login assertion that proves authenticated content actually rendered. — The browser login monitor wizard: paste the login URL, supply a low-privilege test account, and pick a post-login text assertion. Velprove drives a real browser through the form on every run and asserts that Logout appears in the rendered DOM after sign-in.

Monitor 4: Public status page at velprove.com/status/your-page

The Velprove free plan includes 1 status page hosted at velprove.com/status/your-pagewith your custom logo on a Velprove-branded page. The page reads from your monitors and gives customers a place to look during an outage that is not your application itself. Side benefit: linking the status page from your own footer is a credibility signal that says "we know our uptime matters." Custom domains and white-label branding are paid features, but the indie-hacker version of the status page is free and useful on day one.

Velprove public status page hosted at velprove.com/status/velprove showing the Live Status header and a list of monitored services with their current up status, exactly the customer-facing view an indie hacker's users would see when they want to check whether the site is down. — The Velprove status page (the company's own, used here to show the layout) hosted at velprove.com/status/your-page. The free Velprove plan includes one status page at this URL pattern with a Velprove-branded header. This is what your customers see when they want to know whether your side project is down.

What the free tier does not include (and when to upgrade)

Six things the indie hacker outgrows first.

Alert channels: Email only on free. Slack, Discord, Microsoft Teams, and webhook channels open on Starter at $19 per month.
Check interval: 5-minute floor on free. 1-minute on Starter. 30-second plus PagerDuty routing on Pro at $49 per month.
Browser login monitors: 1 on free. 3 on Starter. 10 on Pro.
Status pages: 1 on free. 3 on Pro.
Custom status-page domain: Pro only.
White-label status page: Starter and up.

The honest framing is that the trigger to upgrade is your second paying customer, not the day you sign up. Email alerts to a phone with notifications enabled cover the rotation-of-one for a side project that has not yet earned the operational complexity of a Slack workspace. Cronitor's pricing curve for the same audience starts at $10 per month on the entry tier, which is the comparison anchor most indie hackers actually weigh against. The other axis worth thinking about before paying anyone is whether to self-host Uptime Kuma instead, which is honest work for a developer who already runs servers and wrong work for one who does not.

What the Velprove free tier does include is unusual enough to name explicitly. Velprove allows monitoring from any of 5 global regions on every plan including free, with one region picked per monitor. The Velprove free plan includes a 3-step multi-step API monitor, a real browser login monitor, commercial use with no per-monitor revenue surcharge, and SSL certificate monitoring. Most of those are paywalled on competitor entry tiers. Site24x7 starts at $36 per month for browser monitors, Checkly at $64 per month. The upgrade is when you have revenue to defend, not before.

Why this is not the Vercel and Railway monitoring guide

If your side project lives on Vercel running Next.js, or on Railway with a long-lived service, the platform-specific monitoring details are in the deeper Next.js monitoring walkthrough. That post covers Vercel cold starts, ISR revalidation timing, the auth-protected /dashboard route pattern, and the Railway 10-minute serverless sleep behavior. This post stops at the platform-tier layer: what changed since 2022 and the minimum monitor set on the Velprove free plan. If you came here for Vercel-specific instructions, follow that link.

Frequently Asked Questions

How do I monitor a Render free service that spins down after 15 minutes?

Set a 15-minute interval that matches a realistic user-traffic pattern, accept the cold start as part of the user experience, and upgrade to Render's $7 per month Starter when keeping the service warm matters more than the bill. The reason: Render free web services spin down after 15 minutes of inactivity, and the first request after spin-down takes about 1 minute to complete. The wrong move is to point your monitor at the URL every 5 minutes to keep the service awake. That uses your 750 free monthly instance hours to defeat the spin-down behavior the platform intentionally includes, and you will exceed the cap with two such services.

How many monitors does an indie hacker actually need?

Four covers the load-bearing failure modes for most $0 to $5 per month side projects. One HTTP monitor on the production URL with a body or JSON assertion. One multi-step API monitor on the login or token flow. One browser login monitor on the actual sign-in (the one that signs in like a real user and verifies the post-login screen rendered). One public status page so customers have somewhere to look during an outage. The Velprove free plan allows 10 monitors, so you have 6 spare for staging environments, webhook receivers, and any third-party dependency you cannot live without.

Does Vercel monitor my Hobby app for me?

No. Vercel's Hobby plan is explicitly excluded from the Vercel SLA, and the platform's built-in observability on Hobby retains runtime logs for 1 hour. Vercel does not provide a customer-facing uptime probe on Hobby, and Next.js does not emit a /healthz route by default. The existence of cached error pages or styled error.tsx boundaries means a 200 OK does not prove the route worked. External monitoring is the only way a Vercel Hobby project gets a real uptime signal. The Vercel and Next.js production monitoring walkthrough covers cold starts, ISR revalidation, and /dashboard auth in detail.

Is Fly.io still a free option for a new side project in 2026?

No. Fly.io stopped offering plans to new customers on October 7, 2024. The Fly.io pricing page reads verbatim: "Fly.io no longer offers plans to new customers." Existing customers on legacy Launch or Scale plans retain free allowances of up to three shared-cpu-1x 256MB VMs, but a new account today goes onto Pay As You Go at roughly $0.0028 per hour for the cheapest always-on machine, or about $2 per month per VM in the cheapest regions. Treat Fly.io like any other paid host when evaluating it for a 2026 side project.

Can I use Velprove's free plan for a commercial side project that earns revenue?

Yes. Velprove allows commercial use on every plan, including free, with no per-monitor surcharge for revenue-generating sites. This is the same axis where UptimeRobot's free plan changed in November 2024 to restrict free accounts to personal, non-commercial use. If your side project takes payments, runs ads, or has paying customers, the free Velprove plan is the closest direct replacement that does not require you to read the terms of service every quarter to check whether you are still compliant.

What is the cheapest indie-hacker monitoring stack that includes a real browser login monitor?

Free, on Velprove. The free plan includes one browser login monitor running every 15 minutes that opens a real browser, signs in with credentials you provide, and verifies the post-login page rendered. Most other monitoring tools either gate browser monitors to a paid tier (Site24x7 starts at $36 per month, Checkly at $64 per month) or do not offer them at all (Pingdom, StatusCake on entry tiers). The trade is the 15-minute interval (Pro raises to 30 seconds) and the 1-monitor cap (Starter raises to 3). For a side project, both are acceptable.

Get the 4 monitors running in 10 minutes

The setup above takes about 10 minutes to put in place from a fresh signup. Start a free Velprove account. The Velprove free plan includes 10 monitors, 1 browser login monitor at 15 minutes, multi-step API monitors up to 3 steps, monitoring from any of 5 global regions, email alerts, and 1 status page at velprove.com/status/your-page. No credit card required. Set up the HTTP monitor on your production URL with a body assertion first; that is the highest-value 90 seconds you will spend. Then add the multi-step API monitor on the auth flow, the browser login monitor on the actual sign-in, and turn on the status page. If your side project grows into something with on-call hours and a paying customer base, the solo founder on-call rotation playbook is the next read.