To run this guide from your terminal or your coding agent, run `npx checkly init` in your project first. It installs the Checkly CLI and [Checkly Skills](/ai/skills) for your agent. Then paste the prompt below into Claude Code, Cursor, Codex, or any agent that supports skills. It builds the same setup as this guide, proves it with `npx checkly test --record`, and stops for your confirmation before `npx checkly deploy`.
```txt Prompt theme={null}
Set up uptime monitoring for this project with Checkly so that every public page is covered from one list.
Success criteria:
1. Create `__checks__/group.ts` with a `CheckGroupV2` that runs in parallel from 2 locations, alerts after 1 failed run, and has retries disabled. Export a shared `responseTimes` object with `degradedResponseTime: 3000` and `maxResponseTime: 5000`.
2. Ask me for the public pages of my site. Create `__checks__/pages.check.ts` with an array of `{ id, path }` entries and a loop that creates one `UrlMonitor` per entry, in the group, spreading `responseTimes`, following redirects, and asserting HTTP 200. Use the `id` in the logical ID so it stays stable when I reorder the list.
3. Create `__checks__/certificate.check.ts` with an `SslMonitor` for my hostname in the same group, alerting 14 days before expiry.
4. Tell me which of my pages need more than a status code, and why an API check would be the next step for those.
5. Run `npx checkly test --record` and show me the session link.
6. Show me `npx checkly deploy --preview` and wait for my confirmation before deploying.
Explain each file you changed and why.
```
The steps below are what the agent does, in the open.
## Step 1: Decide what every monitor shares
A shop has a handful of pages a customer can land on, and they all deserve the same treatment: the same locations, the same alert rule, the same idea of what "slow" means. Put those decisions in one place before you write a single monitor, so adding the tenth page costs the same as adding the first.
```ts __checks__/group.ts theme={null}
import { AlertEscalationBuilder, CheckGroupV2, RetryStrategyBuilder } from 'checkly/constructs'
// Every monitor in this guide joins this group and inherits its locations
// and alert policy. Retries are off so a failure shows on the first run.
export const shopGroup = new CheckGroupV2('shop-uptime', {
name: 'Shop uptime',
locations: ['us-east-1', 'eu-west-1'],
runParallel: true,
alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1),
retryStrategy: RetryStrategyBuilder.noRetries(),
})
// Slow is not down: over 3 seconds is degraded, over 5 seconds fails.
export const responseTimes = {
degradedResponseTime: 3000,
maxResponseTime: 5000,
}
```
The group carries locations and the alert policy, because those belong to the group. Response-time thresholds belong to each monitor, so they live in an exported object that every monitor spreads in. Retries are off in this guide so you can see a failure land on the first run. For real monitoring, [Alerting that doesn't wake you up for nothing](/guides/alerting) shows how to turn them back on.
The project config sets the frequency and tag for everything the group does not cover:
```ts checkly.config.ts theme={null}
import { defineConfig } from 'checkly'
import { Frequency } from 'checkly/constructs'
export default defineConfig({
projectName: 'Docs guide: Cover every endpoint with uptime monitors',
logicalId: 'docs-guide-uptime-coverage',
repoUrl: 'https://github.com/checkly/docs',
checks: {
activated: true,
frequency: Frequency.EVERY_1M,
tags: ['guide-uptime-coverage'],
checkMatch: '**/__checks__/**/*.check.ts',
},
cli: { runLocation: 'us-east-1' },
})
```
## Step 2: Turn the list of pages into monitors
Now write down the pages. Not the monitors, the pages. The home page, a product page, the cart, the checkout, and the API the storefront calls. A loop turns each line into a URL monitor that inherits everything from Step 1.
```ts __checks__/pages.check.ts theme={null}
import { UrlAssertionBuilder, UrlMonitor } from 'checkly/constructs'
import { responseTimes, shopGroup } from './group'
// Every page a customer can land on. Add a line here to add a monitor.
// The id becomes part of the logical ID, so keep it stable when you reorder.
const pages = [
{ id: 'home', path: '/' },
{ id: 'book', path: '/books/1' },
{ id: 'cart', path: '/cart' },
{ id: 'checkout', path: '/checkout' },
{ id: 'books-api', path: '/api/books' },
]
for (const { id, path } of pages) {
new UrlMonitor(`shop-${id}`, {
name: `Shop ${path}`,
group: shopGroup,
...responseTimes,
request: {
url: `https://danube-web.shop${path}`,
followRedirects: true,
assertions: [UrlAssertionBuilder.statusCode().equals(200)],
},
})
}
```
When a new page ships, someone adds one line and deploys. When a page is retired, someone deletes one line and the monitor goes with it. The `id` matters more than it looks: Checkly matches a monitor to its history by logical ID, so `shop-cart` keeps its uptime record no matter where it sits in the array. Generate IDs from array positions and a reorder silently creates five new monitors and deletes five old ones.
To follow along without your own app, clone the [sample project](https://github.com/checkly/docs/tree/main/samples/guides/uptime-coverage). It monitors the [Danube demo shop](https://danube-web.shop) and one deliberately slow page on httpbin.org.
## Verify it works
Break both layers on purpose. In `__checks__/slow.check.ts`, change the URL to `https://httpbin.org/status/503`, a page that always answers with a server error. In `__checks__/certificate.check.ts`, change the hostname to `expired.badssl.com`, a host that serves an expired certificate on purpose. Deploy.
Within a minute, the slow page monitor fails from both locations. Its error groups show both what happened and which assertion it broke: a 503 that was expected to equal 200.
The certificate monitor fails too. There is no status code at this layer, so the error names the handshake step that broke:
Change both values back and deploy again. The next run from each location recovers both monitors. Nothing else in the group changed, because everything else was generated from the same list and the same defaults.
## Next
[Monitor the content your customers need to see](/guides/keyword-monitoring): a URL monitor proves a page answered, not what it shows. Assert that the text that sells is on the page, in the right place.
## Reference
* [URL monitors](/detect/uptime-monitoring/url-monitors/overview) and [SSL monitors](/detect/uptime-monitoring/ssl-monitors/overview)
* [API checks](/detect/synthetic-monitoring/api-checks/overview), for when a status code is not enough
* [`UrlMonitor`](/constructs/url-monitor), [`SslMonitor`](/constructs/ssl-monitor), and [`CheckGroupV2`](/constructs/check-group-v2)
* [Checkly Skills](/ai/skills)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.