Introducing the MoniterMySite API, audit log and domain-expiry monitoring

Monitoring that lives in your pipeline

Until today, every monitor on MoniterMySite was created by a person clicking through a form. That is fine for a handful of sites. It stops being fine when a new service ships every week, when a deploy predictably trips an alert, or when an incident bot needs to know what is down. From today the whole product is available over a REST API, on every plan including the free one, with the same validation and plan limits as the dashboard.

The reference lives at monitermysite.com/docs/api, with a request and a response example for every endpoint, and an OpenAPI 3.1 document at /api/v1/openapi.json if you prefer to generate a client.

What you can do with it

Twenty-five endpoints cover the things teams actually automate:

• Monitors: list, create, retrieve, update, delete, pause and resume; run a check on demand; read individual check results and uptime for 24 hours, 7, 30 and 90 days.
• Incidents: list open or resolved incidents with their region timeline, and acknowledge them with a comment from your chat bot or on-call tool.
• Status pages: read pages and components, list announcements, and publish an incident or maintenance announcement, which e-mails confirmed subscribers.
• Maintenance windows: open one when a deploy starts and delete it when it ends, so alerts stay quiet and uptime figures stay honest.
• Alert contacts and regions: manage where alerts go and read the probe addresses you need to allowlist.

A deploy script, end to end

Here is the pattern most teams will start with. The deploy opens a twenty-minute maintenance window, ships, and registers a monitor for the new service with an idempotency key so a retried pipeline step never creates a duplicate.

$ curl -s https://monitermysite.com/api/v1/maintenance-windows \
    -H "Authorization: Bearer $MMS_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{ "name": "Release 4.3", "starts_at": "'$(date -u +%FT%TZ)'", "ends_at": "'$(date -u -v+20M +%FT%TZ)'" }'

$ curl -s https://monitermysite.com/api/v1/monitors \
    -H "Authorization: Bearer $MMS_API_KEY" \
    -H "Content-Type: application/json" \
    -H "Idempotency-Key: $GIT_SHA" \
    -d '{ "name": "Search API", "type": "http", "target": "https://api.acme.com/search/health",
          "interval_sec": 30, "regions": ["nyc3", "fra1", "sgp1"], "confirm_regions": 2, "tags": ["prod"] }'

Both calls answer with the created object, a 201 status and the rate-limit headers, and both are recorded in the workspace audit log under the key's name.

Designed to be boring, in the good way

If you have used the Stripe or GitHub APIs, nothing here will surprise you. Every error has the same shape: a type you can switch on, a more specific code, a human message and, for validation failures, the field that caused it. Lists paginate with starting_after and ending_before cursors and tell you when there is more. Dates are ISO 8601 in UTC. Every response carries a request id you can quote to support.

Swipe sideways to see every column.

Audit log: who changed what

An API makes changes easy to make and easy to lose track of. So every change in a workspace is now recorded: monitors, alert contacts, status pages and announcements, maintenance windows, team membership and roles, API keys, and security events such as enabling two-factor authentication. Each entry names the person or the API key, the client address, the time, and for edits the fields that changed with their old and new values. Secrets are never written to the log.

Entries are recorded on every plan from today, so the history is there when you need it. Reading the log in the dashboard is part of the Growth plan (12 months) and the Summit plan (24 months).

Domain expiry monitoring

A new monitor type for the one dependency every site has and nobody watches. A domain monitor looks the registration up once a day at the registry over RDAP, with WHOIS as the fallback, records the expiry date and the registrar, and sends reminders at 60, 30, 14, 7, 3 and 1 day, plus at a threshold you choose. An expired domain opens an incident like any other outage. It is available through the form and the API, on every plan.

Two-factor authentication and Google sign-in

Accounts can now require a 6-digit code from any authenticator app at sign-in, with eight one-time recovery codes for a lost phone. Disabling it requires a current code too, so a password alone can never switch it off. And if your team lives in Google Workspace, Continue with Google signs you in with one click, linked to your existing account when the address matches. Both live under Settings.

Getting started

Three steps, two minutes:

• Open Developer in the dashboard sidebar and create a key. Pick read-only for dashboards and reporting, read + write for pipelines.
• Call GET /v1/account to see your workspace, plan and limits, and to confirm the key works.
• Read the reference at /docs/api and copy the example closest to what you are building. If an endpoint you need is missing, tell [email protected]; most requests ship within a week.