What you are setting up
Three pieces, in order: an HTTP check against your production URL (and, if you have one, a dedicated health endpoint), the Errors SDK wired into instrumentation.ts so server-side exceptions are captured with no per-route try/catch, and a status page your customers can subscribe to.
Create the checks
From the dashboard (Checks → New check) or the CLI. Watch the page a real visitor hits, and separately a lightweight /api/health route if your app has one, so a failing database connection or a failing edge function show up as two different alerts instead of one ambiguous one.
export REALUPTIME_API_KEY=ru_live_...
realuptime checks create \
--name "My app" \
--url https://myapp.example.com/ \
--interval 60 \
--regions iad,sjc,fra,nrt
realuptime checks create \
--name "My app health" \
--url https://myapp.example.com/api/health \
--interval 60 \
--regions iad,fraSee Checks & monitors for response assertions (a JSON field, a response header, a literal body match) if a 200 status code alone is not enough to tell the app is actually healthy.
Connect RealUptime Errors
Install the SDK and call it once from instrumentation.ts, which the App Router (Next 15+) invokes for every server-side render, Server Action, and Route Handler error with no per-route wiring required.
// instrumentation.ts, at your project root
export async function register() {
// register() also runs under the edge runtime and during `next build`'s
// trace/compile step -- gate to nodejs so neither of those opens a
// transport.
if (process.env.NEXT_RUNTIME !== "nodejs") return;
const { registerErrorTracking } = await import("@realuptime/errors/adapters/nextjs.ts");
registerErrorTracking({ dsn: process.env.REALUPTIME_ERRORS_DSN! });
}
// Next (App Router, 15+) calls this for every server-side rendering,
// Server Action, and Route Handler error. Re-export it verbatim.
export { onRequestError } from "@realuptime/errors/adapters/nextjs.ts";A Route Handler that throws outside of Next's own request lifecycle (a promise you forgot to await, an error thrown after the response already started) needs the explicit wrapper instead:
// app/api/orders/route.ts
import { withRouteErrors } from "@realuptime/errors/adapters/nextjs.ts";
export const GET = withRouteErrors(async (req: Request) => {
// ...
});See Errors quickstarts for the client-side React error boundary if you also want exceptions thrown in the browser, and for what other frameworks look like if part of your stack is not Next.js.
Add a status page
Create a status page from the dashboard (Status pages → New status page) and add the checks above as components. Visitors see per-region state rather than one collapsed badge, and can subscribe to incidents by email, RSS/Atom, or (Growth and up) Slack and webhook. See Status pages for custom domains and branding.
What RealUptime does and does not see
The check sees exactly what a browser or another server sees: the HTTP response, its latency, and its status code, from each region you chose. It does not see your build, your deployment platform's internals, or a request that never left your infrastructure (a Server Action invoked entirely server-side, with no page ever fetched).
Errors sees exceptions your code (or Next's own request lifecycle) reports through the adapter above. It does not see requests that succeed, and it does not see anything about a request's body, headers, or cookies beyond what you explicitly attach as context.
Hosting on Vercel specifically? See RealUptime + Vercel for what changes (there is no server for the Monitor agent to run on).