Skip to content

Set up RealUptime with your AI agent.

Set up RealUptime (https://realuptime.io) for the project in this repository. Work through the steps in order. This prompt is also served as plain text at https://realuptime.io/agents/prompt.txt.

## Rules that apply to every step
- The API key is in the environment variable REALUPTIME_API_KEY. Never print it, echo it, write it to a file, commit it, or put it in a URL or a command argument. Reference it only as $REALUPTIME_API_KEY. If it is not set, stop and ask the user to create a read and write key at https://realuptime.io/account/api-keys and export it. Do not ask them to paste it into the chat.
- Three commands below return a value that is shown once: an Errors DSN (the project's ingest address), a heartbeat ping URL and a server agent token. Run them exactly as written, with --field, so the value goes into a variable and never into your output. Never print one, echo one, or commit one.
- Stay inside the Free plan limits: at most 10 monitors (heartbeats count), a check interval of 60 seconds or slower, only the regions iad, sjc, fra, nrt, 1 status page, 2 Errors projects, 5 servers, and 5 registered notification channels. The API is part of every plan, Free included; a Free account has a budget of 60 API requests per minute across all its keys, so run the commands one at a time.
- If any command is refused (it exits non-zero, with HTTP 403 or 429 or a code starting with RU-), stop. Do not retry and do not try a different route around it. Tell the user the exact error text and code, which limit or plan it came from, and what they could change.
- Ask the user before anything that notifies real people or publishes a public page.
- Create only what the plan below lists. Do not delete or change monitors, pages, channels, projects or agents that already exist.

## Step 1: inspect this repository
Read the repository and find: the language and framework, the deploy target, every public URL and domain, health endpoints (for example /health, /healthz, /api/health), background jobs or cron tasks, where the project keeps environment variables and whether that file is ignored by git, and whether you control any servers. Change nothing in this step.

## Step 2: propose a plan and wait
Show the user a plan before changing anything: the monitors you would create (name, URL, interval), a heartbeat for each scheduled job, the status page components, which Errors SDK you would add and where, whether a server agent applies, and the alert destinations. Keep it within the limits above. Wait for the user to approve the plan.

## Step 3: install the CLI and check the key
Install the CLI:
brew install realuptimehq/realuptime/realuptime
If Homebrew is not available, install it with npm (Node 22 or newer):
npm install -g @realuptime/cli
Check the key works. This lists the monitors that already exist:
realuptime checks list --json
If this is refused, stop and report it.
Check the CLI is current. This lists the Errors projects; if the CLI answers that it does not know the subcommand, upgrade the CLI before going on:
realuptime errors projects list --json

## Step 4: create monitors
Create one monitor per approved URL, one command each. Use https URLs only, an interval of 60 seconds or more, and the default regions (omit --regions, or list only iad,sjc,fra,nrt):
realuptime checks create --name "<name>" --url "<https url>" --interval 60 --json
Record the id of every monitor created. Stop at 10 monitors counting the ones that already exist.
For each scheduled job the user approved, create a heartbeat and store its ping URL in the project's environment under a name of its own, in one command. <env file> is the file the project loads its environment from; it must be ignored by git (check with git check-ignore), and if none is, stop and tell the user:
PING_URL="$(realuptime heartbeats create --name "<job name>" --interval <seconds between runs> --grace <seconds late allowed> --field pingUrl)" && printf '%s=%s\n' "<JOB>_HEARTBEAT_URL" "$PING_URL" >> "<env file>"
Then make the job request that URL when it finishes, reading it from the variable. For a job named BACKUP, its last line would be: curl -fsS "$BACKUP_HEARTBEAT_URL"

## Step 5: set up the status page
List the status pages. A Free account includes 1, and it usually exists already:
realuptime status-pages list --json
If one exists, use its id and its public_url. Only if none exists, ask the user, then create one:
realuptime status-pages create --name "<project name> status" --json
See what the page already shows:
realuptime components list --status-page-id "<status page id>" --json
Tell the user the page address (public_url) and which monitors you would add to it, and ask for confirmation, because the page is public. Then add one component per monitor that is not on the page yet, one command each:
realuptime components add --status-page-id "<status page id>" --check-id "<monitor id>" --name "<component name>" --json

## Step 6: add error tracking
If the project's environment already defines REALUPTIME_ERRORS_DSN, keep it and skip to the SDK. Otherwise look at the Errors projects you listed in step 3. A Free account includes 2; an existing project's DSN cannot be read again, so a new project is the way to get one.
Create the project and write its DSN straight into the project's environment file, in one command, so it never appears in your output:
REALUPTIME_ERRORS_DSN="$(realuptime errors projects create --name "<project name>" --field dsn)" && printf 'REALUPTIME_ERRORS_DSN=%s\n' "$REALUPTIME_ERRORS_DSN" >> "<env file>"
Add the same variable to the deploy target with that platform's own command, passing "$REALUPTIME_ERRORS_DSN" and never the value typed out. Add REALUPTIME_ERRORS_DSN to any committed example env file by name only.
Install the SDK for the detected language, and call init with dsn taken from REALUPTIME_ERRORS_DSN:
JavaScript or TypeScript: npm install @realuptime/errors
Python: pip install realuptime-errors
Go: go get github.com/RealUptimeHQ/realuptime-errors-go
PHP: composer require realuptime/errors:dev-main
Ruby: add gem "realuptime-errors" to the Gemfile
Framework adapters (Next.js, Express, Django, Flask, FastAPI, Celery) are documented at https://docs.realuptime.io/errors-quickstarts. Use the adapter that matches the project.
Send one test event, in the same shell as the create command so REALUPTIME_ERRORS_DSN is set:
curl -sS -X POST "$REALUPTIME_ERRORS_DSN" -H "content-type: application/json" -d '{"events":[{"occurredAt":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'","message":"realuptime errors test event","exceptionType":"TestError","release":null,"environment":"test","frames":null,"request":null,"fingerprint":null}]}'
Confirm it arrived. Find the new project's id, then list its issues:
realuptime errors projects list --json
realuptime errors issues list --project-id "<project id>" --json

## Step 7: alert destinations
See where alerts go today:
realuptime channels list --json
Email to the account owner is built in. This command creates nothing and notifies nobody; it confirms the destination and whether it is active:
realuptime channels create --type email --json
If active is false, the account's alert rules leave email out. Tell the user; do not change the rule.
Optional, Slack: ask the user whether they want alerts in Slack. If yes, ask them to export the Slack incoming webhook URL as REALUPTIME_ALERT_WEBHOOK_URL in the environment you run commands in, then run this. The CLI reads the URL from that variable, so it is never typed:
realuptime channels create --type slack --json
An account has one Slack webhook. If one is already set, this is refused: keep the existing one and say so.

## Step 8 (only if a server was detected): server agent
Only if the repository shows a server you control, and only after the user says yes. Run this on that server, where the CLI and REALUPTIME_API_KEY are available. It registers the agent and installs it in one command, and the token never appears in your output:
REALUPTIME_AGENT_TOKEN="$(realuptime agent token create --name "<server name>" --field token)" && curl -fsSL https://realuptime.io/agent/get | REALUPTIME_TOKEN="$REALUPTIME_AGENT_TOKEN" sh
If you are not running on that server, do not create the token: tell the user this step runs on the server itself. A Free account covers 5 servers.

## Step 9: report
Give the user: the status page address, a table of everything created with its id (monitors, heartbeats, components, Errors project, agent), where alerts go, the names of the environment variables you added and the files you added them to, and what was skipped and why. Do not include any key, token, DSN or ping URL in the report.

Plain text for an agent to fetch: /agents/prompt.txt

What the agent will do

  • Read your repository and propose a plan. Nothing changes until you approve it.
  • Create uptime monitors for your real endpoints, and a heartbeat for each scheduled job.
  • Put those monitors on your status page, after you confirm.
  • Create an Errors project, add the SDK for your language and send one test event.
  • Confirm alert email reaches the account owner, and connect Slack if you say yes.
  • Install the server agent, if you have a server and say yes.
  • Show you the status page address and every id it created.

What it needs from you

  • A RealUptime account: sign up free.
  • An API key with read and write access, created at API keys, exported as REALUPTIME_API_KEY.

The Free plan covers it: up to 10 monitors, one status page and 5 notification channels. The agent stops and tells you when a limit is reached.

What it will never do

  • Print your key, write it to a file, commit it, or put it in a URL.
  • Print a DSN, a ping URL or an agent token. Each goes straight into your environment.
  • Publish a page or notify anyone without asking you first.
  • Delete or change what already exists in your account.
  • Retry a refused command or go past your plan's limits.

Prefer to run the commands yourself? See the CLI reference and the API reference.