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 "" --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. 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 "" --interval --grace --field pingUrl)" && printf '%s=%s\n' "_HEARTBEAT_URL" "$PING_URL" >> "" 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 " status" --json See what the page already shows: realuptime components list --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 "" --check-id "" --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 "" --field dsn)" && printf 'REALUPTIME_ERRORS_DSN=%s\n' "$REALUPTIME_ERRORS_DSN" >> "" 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 "" --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 "" --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.