Invite workspace members, understand owner and member access, and manage invitations and seats.

Team Access

API Reference

The Statusfield REST API (v2) gives you read-only, programmatic access to the same <ServiceCount /> vendor status catalog that powers your dashboard and alerts. Every endpoint returns JSON, is authenticated with a Bearer token, and is served from the base URL https://statusfield.com.

Use it to check whether a service is degraded, list the monitors in your workspace, or pull a live snapshot of your monitored catalog services currently down.

<Callout variant='info' title='Paid Plan Required'>
  The API is available on the Starter plan and up. It is not available on
  the Basic plan — Basic-plan keys return 403 planrestriction. Upgrade your
  plan to get started.
</Callout>

Authentication

All endpoints require an API key passed as a Bearer token:

<Steps>
  <Step title="Create a Key">
    Go to Settings → Integrations → API Keys
    and create a new key. The key is shown only once at creation time, so copy
    it somewhere safe. You can revoke a key from the same screen at any time.
  </Step>

  <Step title="Make Your First Call">
    Pass the key in the Authorization header on every request:

    

  </Step>
</Steps>

Keys are scoped to the workspace that created them. Rate limits, quotas, and available features all follow that workspace's plan.

Rate Limits & Quota

Limits are enforced per workspace per minute, with a per-second burst ceiling. The X-RateLimit-Limit and X-RateLimit-Remaining headers are returned on every response. When you exceed a limit you get 429 ratelimited along with a Retry-After (seconds) header.

<ApiPlanLimits />

The monthly quota is enforced per workspace and tracked in the database, so it survives restarts and is accurate across instances. For plans with a finite cap, responses include X-Quota-Limit, X-Quota-Remaining, and X-Quota-Reset (ISO timestamp of the next UTC-month reset) headers. Exceeding the cap returns 429 quotaexceeded. The monthly counter resets at the start of each UTC month.

<Callout variant='info' title='Check the Headers'>
  Read X-RateLimit-Remaining to pace short bursts and X-Quota-Remaining to
  track your monthly budget. On a 429, honor Retry-After for burst limits;
  for quotaexceeded, wait until X-Quota-Reset or review your plan.
</Callout>

Error Shape

All errors follow the same JSON shape:

| HTTP Status | error code         | Meaning                                              |
| ----------- | -------------------- | ---------------------------------------------------- |
| 400         | badrequest        | Missing or invalid parameter (e.g. slug)             |
| 401         | unauthorized       | Missing Authorization header or invalid key format |
| 401         | invalidkey        | API key not found                                    |
| 403         | banned             | Account suspended or inactive                        |
| 403         | expired            | Temporary access expired                             |
| 403         | planrestriction   | Feature not available on current plan                |
| 404         | notfound          | Resource does not exist                              |
| 405         | methodnotallowed | Wrong HTTP method                                    |
| 429         | ratelimited       | Rate limit exceeded; see Retry-After               |
| 429         | quotaexceeded     | Monthly request quota exceeded                       |

List Services

GET /api/v2/services

List the Statusfield service catalog with optional filtering and cursor-based pagination.

Query parameters:

| Parameter  | Type   | Default | Max | Description                                      |
| ---------- | ------ | ------- | --- | ------------------------------------------------ |
| category | string | —       | —   | Filter by category code (e.g. cloudcomputing) |
| search   | string | —       | —   | Full-text search on service name                 |
| cursor   | string | —       | —   | Opaque cursor from a previous response           |
| limit    | number | 50      | 100 | Number of results per page                       |

Pass pagination.nextCursor from a response as the cursor on your next request to page through results. Keep going while pagination.hasMore is true.

Response 200:

Example:

Get a Service

GET /api/v2/services/{slug}

Get the current status of a service your workspace actively monitors and its components. A catalog match alone does not grant status access.

Path parameter: slug — the service's URL slug (e.g. github).

Response 200:

Returns 400 badrequest if the slug is missing or invalid, 403 servicenotmonitored if the workspace does not actively monitor it, and 404 notfound if the service does not exist.

Example:

List Monitors

GET /api/v2/monitors

List all monitors belonging to the authenticated workspace.

Response 200:

Each monitor carries a type describing its kind and an isCustom flag:

| type    | isCustom | Meaning                                                |
| --------- | :--------: | ------------------------------------------------------ |
| catalog |  false   | A monitor on a Statusfield catalog (3rd-party) service |
| http    |   true   | Your custom URL / server-response (uptime) monitor     |
| ssl     |   true   | Your custom SSL-certificate-expiry monitor             |
| domain  |   true   | Your custom domain-registration-expiry monitor         |
| custom  |   true   | A custom monitor with no more specific kind            |

expiresAt is the upcoming expiry date (ISO 8601) for ssl / domain monitors, and null for all other types.

Query parameters:

| Parameter | Type   | Default | Description                                                                             |
| --------- | ------ | ------- | --------------------------------------------------------------------------------------- |
| filter  | string | —       | outages returns only monitors whose component is currently in a non-operational state |

Example:

List Outages

GET /api/v2/outages

List actively monitored catalog services in your workspace currently experiencing an outage or degradation. For workspace-private custom monitors, use /api/v2/monitors?filter=outages.

Query parameters:

| Parameter | Type   | Default | Max | Description                 |
| --------- | ------ | ------- | --- | --------------------------- |
| limit   | number | 100     | 200 | Number of outages to return |

Response 200:

A non-operational service is anything not in OPERATIONAL, REROUTED, or PARTIALLYREROUTED. Custom (workspace-private) monitors are never included. The list is a bounded snapshot — there is no pagination.

Example:

Using the Same Key from AI Tools

Your sf_ key also works with the Statusfield MCP server, so AI tools like Claude can query live status directly. See the MCP Server guide to connect it.

For the current per-plan request and quota limits, see Pricing.

Query the live status of thousands of services over a read-only REST API. Bearer-authenticated JSON, available on the Starter plan and up.

<DocsTask
  featured
  title='Start with your first monitor'
  description='Choose vendor, uptime or heartbeat monitoring. Set up the first monitor and check that its alerts reach you.'
  href='/docs/quickstart'
/>

What would you like to do?

<CardGroup cols={2}>
  <DocsTask
    title='Check your website or API'
    description='Set the response codes, latency and response content that count as healthy.'
    href='/docs/quickstart#monitor-your-own-website-or-api'
  />
  <DocsTask
    title='Catch a job that stops running'
    description='Send a check-in after successful work and watch for a missed deadline.'
    href='/docs/quickstart#monitor-a-cron-job-backup-or-sync'
  />
  <DocsTask
    title='Set up alert destinations'
    description='Connect your channels and decide which updates reach your team.'
    href='/docs/integrations'
  />
  <DocsTask
    title='Invite your team'
    description='Understand workspace access, member roles, and invitations.'
    href='/docs/team-access'
  />
  <DocsTask
    title='Build with the API'
    description='Read service status and monitored dependencies from your own tools.'
    href='/docs/api'
  />
  <DocsTask
    title='Connect an AI assistant'
    description='Use the MCP server to ask about your vendors and monitoring workspace.'
    href='/docs/mcp'
  />
</CardGroup>

Connect your team's tools

Start with a setup guide for Slack, Microsoft Teams, PagerDuty, email, or webhooks. See all integrations for more destinations and workflows.

<Callout variant='info' title='Need a hand?'>
  Contact support through the in-app chat or email
  us. For plan features and trial details, see
  pricing.
</Callout>

Set up monitoring, choose where alerts go, and connect the tools your team uses.

Make Statusfield work for your team.

Route detected status changes to your Discord channels. Choose the monitors and events the channel should receive. Color-coded embeds show the reported severity at a glance.

<Callout variant='info' title='Paid Plan Required'>
  Discord notifications are available on the Starter, Pro, and Team plans.
  Upgrade your plan to get started.
</Callout>

Quick Start

<Steps>
  <Step title="Create a Discord Webhook">
    In your Discord server:
    1. Right-click the channel where you want notifications
    2. Select Edit Channel
    3. Go to Integrations > Webhooks
    4. Click New Webhook
    5. Name it "Statusfield" (optional)
    6. Click Copy Webhook URL

    <Callout variant="info" title="Permissions">
    You need Manage Webhooks permission in the Discord channel to create a webhook.
    </Callout>

  </Step>

  <Step title="Add Webhook to Statusfield">
    1. Go to statusfield.com/integrations
    2. Click the Discord card
    3. Click Add Discord Integration
    4. Enter a name (e.g., "#incidents", "DevOps Alerts")
    5. Paste the Discord webhook URL
    6. Click Add Discord

  </Step>

  <Step title="Test It Out">
    1. Click the menu (⋮) next to your Discord integration
    2. Select Test Notification
    3. Check that the test message appears in your Discord channel

  </Step>

  <Step title="Configure Notifications">
    When adding a monitor for a service:
    1. Go to statusfield.com/notifications
    2. Find the service in the list
    3. Configure when you want to receive notifications (status by column)
      - On any status change
      - On maintenance status
      - On degraded status
      - On major outage status
      - On partial outage status

    A destination alerted about an incident also receives its recovery while the destination and alert rule remain active. Use Recovery only for destinations that only need the all-clear.

  </Step>

</Steps>

Discord Message Format

Notifications appear as rich embeds in your Discord channel with color-coded borders:

- 🟢 Green — Operational
- 🟡 Yellow — Degraded
- 🟠 Orange — Partial Outage
- 🔴 Red — Major Outage
- ⚪ Gray — Maintenance

Each embed includes:

- Title — Service name and status change (e.g., "GitHub — Status Changed")
- Description — What changed (e.g., "API Requests is now Degraded")
- Current Status — The new status
- Previous Status — What the status was before the change
- Affected Components — List of impacted components (if applicable)
- Timestamp — When the change occurred
- Link — Click the embed title to view the service on Statusfield

Managing Discord Integrations

Add Multiple Channels

You can add multiple Discord webhooks (up to your plan limit) for:

- Different Discord servers
- Separate channels for different severity levels
- Team-specific alert channels

Each Discord integration can be configured independently for different services and notification levels.

Edit or Remove

1. Open statusfield.com/integrations > Discord
2. Click the menu (⋮) next to the integration
3. Select Edit to update the name or webhook URL
4. Select Delete to remove the integration

<Callout variant='warning' title='Warning'>
  Deleting a Discord integration removes all associated notification rules. This
  cannot be undone.
</Callout>

Troubleshooting

<Callout variant="warning" title="Not Receiving Discord Notifications?">
Common issues and solutions:

1. Webhook Was Deleted in Discord

- If someone deletes the webhook in Discord settings, notifications will fail silently
- Create a new webhook in Discord and update the URL in Statusfield

2. Channel Was Deleted or Archived

- Discord webhooks stop working if the target channel is removed
- Create a new webhook in an active channel

3. Webhook URL Is Invalid

- Discord webhook URLs must match the format: https://discord.com/api/webhooks/...
- Make sure you copied the full URL from Discord

4. Rate Limits

- Discord has rate limits on webhook messages
- If you're monitoring many services with frequent status changes, some messages may be delayed

</Callout>

Security & Privacy

- Webhook URLs are encrypted in our database
- All communication with Discord uses HTTPS
- We only send messages — we never read your Discord messages, channels, or user data
- No Discord bot is installed in your server

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Send service status notifications to your Discord channels

Discord

Send monitoring updates to the inbox your team already checks. Statusfield queues email alerts for detected changes that match your notification rules. Confirm delivery with a test email; processing and mail filters can affect when messages arrive.

<Callout variant='success' title='Default Email Address'>
  Your sign up email address is automatically added as an email address for
  notifications and used as your default email address for notifications for
  each new monitor you add. You can change the monitor's notification channels
  in statusfield.com/notifications
</Callout>

Quick Start

<Steps>
  <Step title="Add an Email Address">
    1. Go to statusfield.com/integrations
    2. Click the Email card
    3. Click Add Email Address
    4. Enter a name (e.g., "Personal", "Team Lead") and email address
    5. Click Add Email
  </Step>

  <Step title="Verify Your Email">
    Check your inbox for a verification email from no-reply@send.statusfield.com. Click the verification link to activate notifications.

    <Callout variant="warning" title="Verification Required">
    Email notifications won't be sent until you verify your email address. The verification link expires after 24 hours.
    </Callout>

  </Step>

  <Step title="Test Your Setup">
    1. Click the menu (⋮) next to your email integration
    2. Select Test Email
    3. Check that the test message appears in your email inbox

  </Step>

  <Step title="Configure Notifications">
    When adding a monitor for a service:
    1. Go to statusfield.com/notifications
    2. Find the service in the list
    3. Configure when you want to receive notifications (status by column)
      - On any status change
      - On maintenance status
      - On degraded status
      - On major outage status
      - On partial outage status

    A destination alerted about an incident also receives its recovery while the destination and alert rule remain active. Use Recovery only for destinations that only need the all-clear.

  </Step>

</Steps>

Email Contents

Each notification email includes:

- Subject line - Service name and current status (e.g., "GitHub - Partial Outage")
- Service details - Which service and components are affected
- Status information - Current status with severity level
- Affected components - Complete list of impacted components
- Link - Button linking to full incident details on Statusfield

Managing Email Addresses

Add Multiple Emails

You can add multiple email addresses (up to your plan limit) for:

- Personal backup addresses
- Team distribution (e.g., "DevOps Team", "On-Call Engineer")
- Different departments
- External stakeholders

Each email can be configured independently for different services and notification levels.

<Callout variant='warning' title='Note'>
  Your default email (account email) cannot be edited or removed from
  integrations.
</Callout>

Troubleshooting Delivery

<Callout variant="warning" title="Not Receiving Emails?">
Common issues and solutions:

1. Check Spam Folder

- Look for emails from @send.statusfield.com
- Mark as "Not Spam" and add to safe senders

2. Verify Email Status

- Go to statusfield.com/integrations > Email
- Look for "Pending" badge > click (⋮) > Resend Verification

3. Corporate Email Filters

- Some organizations may delay delivery due to spam filters. Wait a few minutes and check your spam/junk folder.
- Some organizations (especially with Mimecast, Proofpoint) block automated emails
- Contact your IT department to whitelist send.statusfield.com
- Try adding a personal email (Gmail, Outlook) as backup

4. Email Forwarding Rules

- Check if you have filters that auto-archive or delete automated emails
- Ensure Statusfield emails aren't being automatically filtered

5. Inbox Full

- If your mailbox is full, you won't receive new emails
- Clear space and try sending a test email

</Callout>

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Emails

<span id='available-integrations' className='block scroll-mt-24' />

Team alerts

Bring status updates to the people who need them, in the channels they already use.

<DocsIntegrationCards group='alerts' />

<span id='advanced-automation-with-webhooks' className='block scroll-mt-24' />

Automation

Turn a status change into the next step in your workflow.

<DocsIntegrationCards group='automation' />

API & feeds

Read your monitoring data from an application, an AI assistant, or a feed reader.

<DocsIntegrationCards group='data' />

<span id='multiple-notification-channels' className='block scroll-mt-24' />
<span id='integration-features' className='block scroll-mt-24' />

<Callout variant='info' title='Connect it. Assign it. Test it.'>
  For alert destinations, connect your channel, assign notification rules, and
  verify delivery before relying on it. You can use several destinations
  together, such as Slack for team visibility and webhooks for automation.
  Features and integration limits depend on your plan. Compare
  plans.
</Callout>

Connect your team's tools for alerts, automation, and access to monitoring data.

Integrations

Send vendor status updates to the IT channel responsible for your business tools. Statusfield uses a Teams incoming webhook; your organization must allow the required workflow. Check pricing for channel availability and integration limits.

Create a Teams destination

1. Open Workflows in Teams and choose a template that posts webhook alerts to a channel.
2. Select the team and channel that should receive vendor updates.
3. Use a webhook that accepts external requests without Microsoft user authentication. Statusfield sends to the signed URL and does not sign in to your tenant.
4. Save the workflow and copy its webhook URL. Treat the URL as a secret: anyone with a usable URL can send requests to it.

Microsoft's incoming webhook instructions cover the current template names and setup screens. Tenant policies can limit the available options.

Connect it to Statusfield

1. Open Integrations and choose Microsoft Teams.
2. Add an integration, give it a recognizable name such as “IT vendor alerts,” and paste the webhook URL.
3. Create the integration. Open its menu and use Test.
4. Confirm the labeled test appears in the intended Teams channel.

The current connector accepts HTTPS webhook URLs on .logic.azure.com and .webhook.office.com. If Microsoft supplies a different host, the connector will reject it; do not rewrite the URL to bypass validation. Use another supported alert destination while requesting support for that URL format. Existing legacy URLs are subject to Microsoft's connector lifecycle; use Workflows for new setup.

Assign vendor alerts

Open Notifications, select the relevant monitors, and assign the Teams destination and severity filters. Choose provider components where available. Test delivery before relying on the channel during an incident.

For example, route collaboration-tool updates to the help desk channel. Share a separate status board with staff who only need to check reported status. A Teams integration and a staff status board are configured separately; creating either does not automatically subscribe everyone to notifications.

If something fails

- Workflows unavailable: ask your Microsoft 365 administrator whether your account and tenant allow them.
- URL rejected: check that the complete, unmodified HTTPS URL uses a supported host.
- Request unauthorized: check the workflow's authentication setting; a workflow requiring a Microsoft user token cannot accept this connector's request.
- Test sent but no message visible: inspect the workflow's run history, its Teams connection, and the chosen channel. Fix any failed action, then retry the test.
- Test works but no incidents arrive: check active monitoring, plan entitlement, selected components, destination and severity rules. A matching vendor status change may not have occurred.

An incoming webhook request is only part of the delivery path. Confirm the message in Teams. A labeled test is delivery evidence, not a real outage. Keep an alternative communication channel for incidents affecting Teams itself.

Continue with the IT workflow or quickstart.

Route vendor status updates to an IT channel and verify delivery using a Teams workflow

Microsoft Teams

Connect Statusfield to n8n using a webhook trigger. When a monitored service goes down, degrades, or recovers, Statusfield fires an HTTP POST to your n8n workflow — no npm package or coding required.

<Callout variant='info' title='Paid Plan Required'>
  Webhook notifications are available on the Starter, Pro, and Team plans.
  Upgrade your plan to get started.
</Callout>

Quick Start

<Steps>
  <Step title="Create a Webhook trigger in n8n">
    In your n8n workspace:
    1. Click New Workflow
    2. Add a Webhook node as the trigger
    3. Set HTTP Method to POST
    4. Set Response Mode to Respond Immediately
    5. Click Listen for Test Event to activate the URL
    6. Copy the Webhook URL shown in the node

    <Callout variant="info" title="Production URL">
      n8n shows a Test URL and a Production URL. Use the Test URL while setting up,
      then switch to the Production URL once your workflow is working.
    </Callout>

  </Step>

<Step title='Add a Webhook integration in Statusfield'>
  1. Go to statusfield.com/integrations
  2. Click the Webhooks card 3. Click Add Webhook 4. Enter a name (e.g.,
  "n8n — incident workflow") 5. Paste the n8n Webhook URL 6. Leave method as
  POST 7. Click Add Webhook
</Step>

  <Step title="Test the connection">
    1. Click the menu (⋮) next to your webhook integration
    2. Select Test Notification
    3. In n8n, check that the test event arrived in your Webhook node

    The payload will look like:

    

  </Step>

  <Step title="Build your workflow">
    With the payload arriving, add nodes after the Webhook trigger to do whatever you need:

    - Send a Slack message — pass service and status into a Slack node
    - Create a Jira ticket — open an incident when status is majoroutage
    - Page on-call — call an OpsGenie or PagerDuty node
    - Log to a spreadsheet — write every status change to Google Sheets

    When you're done, click Activate to switch to the Production URL.

  </Step>

  <Step title="Configure notification rules">
    1. Go to statusfield.com/notifications
    2. Find the service you want to trigger your workflow
    3. Enable notifications for the statuses that matter to you
  </Step>
</Steps>

Payload Reference

Statusfield sends a JSON body on every status change:

| Field            | Type   | Description                                                                            |
| ---------------- | ------ | -------------------------------------------------------------------------------------- |
| service        | string | Human-readable service name (e.g., "GitHub")                                           |
| serviceSlug    | string | URL slug (e.g., "github")                                                              |
| component      | string | Affected component name                                                                |
| status         | string | New status: operational, degraded, partialoutage, majoroutage, maintenance |
| previousStatus | string | Status before this change                                                              |
| timestamp      | string | ISO 8601 UTC timestamp                                                                 |
| url            | string | Statusfield page for this service                                                      |

Tips

Filter by severity in n8n — Add an If node after the Webhook trigger to branch on status:

- Route majoroutage to a PagerDuty call
- Route degraded to a Slack message
- Route operational (recovery) to close the incident

Use the Production URL — The Test URL in n8n only works when the workflow is open and in test mode. Switch to the Production URL before saving your Statusfield webhook.

Troubleshooting

<Callout variant="warning" title="Not receiving events in n8n?">

1. Test URL vs Production URL

The Test URL only accepts events while the workflow editor is open with "Listen for Test Event" active. For live events, activate the workflow and use the Production URL.

2. Workflow is not active

In n8n, check the toggle in the top-right of the workflow editor. The workflow must be Active to receive production events.

3. Webhook URL changed

If you re-create the Webhook node in n8n, the URL changes. Update the URL in statusfield.com/integrations.

</Callout>

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Trigger n8n workflows when monitored services change status

Route selected Statusfield status changes into PagerDuty for your on-call team. A matching rule sends a trigger event; a detected return to Operational sends a resolve event. Keep the destination and alert rule active so recovery can reach PagerDuty.

<Callout variant='info' title='Plan Availability'>
  PagerDuty is available on higher-tier plans. See the pricing
  page for current availability, or open the PagerDuty card on
  your integrations page to check
  whether it's included in your plan.
</Callout>

How It Works

Statusfield uses PagerDuty's Events API V2 to send status changes that match your notification rules:

- Selected problem states trigger an incident: the summary names the service and its new status.
- Recovery sends a resolve event: when the monitored service returns to Operational, Statusfield sends a resolution for the matching incident.
- Related updates share an incident key: vendor component changes use the same service key. Regional endpoint checks use separate keys so recovery in one location does not resolve another location’s incident.
- Severity follows status: outages map to higher PagerDuty severities (critical / error), lesser issues to warning.

<Callout variant='info' title='Choose what should page you'>
  Select the problem states that need an on-call response. Repeated updates
  with the same key can update an open incident. A new failure after recovery
  can open another incident; your PagerDuty service controls escalation and
  responder notifications.
</Callout>

Quick Start

<Steps>
  <Step title="Create an Events API V2 Integration in PagerDuty">
    In your PagerDuty account:
    1. Open the Service you want alerts on (or create one)
    2. Go to the Integrations tab → Add integration
    3. Choose Events API V2
    4. Copy the generated Integration Key (also called the routing key) — it's a 32-character string

    <Callout variant='info' title='Where the incident lands'>
      The PagerDuty Service you attach the integration to determines which
      escalation policy and on-call schedule handle the alert. Pick the Service
      whose responders should react to this outage.
    </Callout>
  </Step>

  <Step title="Add the Integration to Statusfield">
    1. Go to statusfield.com/integrations
    2. Click the PagerDuty card
    3. Give it a Name (e.g., "On-call escalation")
    4. Paste your Routing Key (Integration Key)
    5. Click Create
  </Step>

  <Step title="Test It Out">
    1. Click the menu (⋮) next to your PagerDuty integration
    2. Select Test Notification
    3. Confirm the labeled test incident appears in PagerDuty. Statusfield also sends a follow-up resolve event; check that it resolves, and close it manually if the follow-up did not arrive.
  </Step>

  <Step title="Configure Notifications">
    When adding a monitor for a service:
    1. Go to statusfield.com/notifications
    2. Find the service in the list
    3. Choose which status changes should page you (any change, degraded, partial outage, major outage, maintenance)

    Statusfield sends a resolve event when the monitored service returns to Operational. Keep the destination and its alert rule active so the recovery event can be delivered.
  </Step>
</Steps>

Incident Format

Each PagerDuty incident Statusfield opens includes:

- Summary — the service name and its new status (e.g., "GitHub: Major Outage")
- Source — statusfield.com
- Severity — mapped from the service status (critical, error, warning, or info)
- Dedup key: shared by related updates and their recovery, with separate keys for regional endpoint checks

Troubleshooting

<Callout variant='warning' title='Not Receiving PagerDuty Incidents?'>
  Common issues and solutions:

1. Invalid routing key

- The routing key must be the Integration Key from an Events API V2
  integration (32 characters). Keys from other integration types won't work.
- Re-copy the key from PagerDuty and update the integration in Statusfield.

2. Incident opened but nobody was paged

- Check the escalation policy on the PagerDuty Service you attached the
  integration to — the on-call schedule there controls who gets notified.

3. Incident didn't resolve

- Check whether the monitor has returned to Operational and whether the
  destination and its notification rule are still active. If Statusfield sent
  a resolve event, check its delivery result and the matching PagerDuty incident.

</Callout>

Security & Privacy

- Routing keys are stored encrypted in our database.
- Statusfield only sends incident triggers and resolves — it never reads your
  PagerDuty incidents, schedules, or user data.
- All PagerDuty API calls use HTTPS.

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Trigger and auto-resolve PagerDuty incidents when monitored services go down

PagerDuty

Prefer to pull status updates instead of receiving pushed alerts? Statusfield publishes RSS and Atom feeds you can subscribe to in any feed reader, or wire into tools like Slack, Zapier, or a status dashboard.

There are two kinds of feed:

<CardGroup cols={2}>
  <Card
    title='Per-Service Status Feed'
    description='Public feed of status changes for a single service'
  />
  <Card
    title='Your Monitors Feed'
    description='One feed covering every service you monitor'
  />
</CardGroup>

Per-Service Status Feed

Every public service page has its own feed of status changes — no account or key required. It mirrors the last 7 days of the public service page.

- Swap .rss for .atom if your reader prefers Atom.
- Add ?format=slack for Slack-friendly formatting (see below).

<Callout variant='info' title='Finding the URL'>
  Open any service page on Statusfield and use its RSS link, or just append
  /feed.rss to the service URL.
</Callout>

Your Monitors Feed

Get a single feed covering all the services you monitor, so you don't have to subscribe to each one individually.

- Swap .rss for .atom for an Atom feed.
- Add ?format=slack for Slack-friendly formatting.
- The key is your workspace RSS Key — copy it (and the ready-made feed URL) from Settings → RSS at statusfield.com/settings?tab=rss.

<Callout variant='warning' title='Keep Your Feed Key Private'>
  Anyone with your feed URL can see the list of services you monitor and their
  status history. Treat the key like a password and don't post the URL
  publicly.
</Callout>

<Callout variant='info' title='History Window'>
  How far back the monitors feed reaches depends on your plan. See the pricing
  page for details. The per-service public feed always covers the
  last 7 days.
</Callout>

Slack-Friendly Formatting

Both feeds accept ?format=slack, which formats each entry so it renders cleanly when piped into Slack (for example via Slack's /feed subscribe or an automation tool):

What's in a Feed Entry

Each entry represents a status change and includes:

- Title — the service (or component) name and its new status, with a status emoji
- Description — affected components and a link back to the incident on Statusfield
- Timestamp — when the change was detected
- Stable identifiers — entries keep a stable ID across polls, so your reader won't re-flag old changes as unread

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Subscribe to service status changes with RSS or Atom feeds

RSS Feeds

Send selected vendor status changes and recovery updates to the engineering channel responsible for that dependency. This guide covers setup, permissions, delivery checks, and troubleshooting. Check pricing for the plan that includes Slack and the integration capacity you need.

Overview

Statusfield supports two types of Slack integration:

1. OAuth Channels (Recommended) - Connect your Slack workspace and select channels from a list
2. Incoming Webhooks - Use Slack webhook URLs for simple one-way notifications

<Callout variant='info' title='Which Method Should I Use?'>
  OAuth lets you connect a workspace and select channels. Use an incoming
  webhook when your team already manages one for the destination. Workspace
  policy may require an administrator to approve either method.
</Callout>

Quick Start: OAuth Channels

<Steps>
  <Step title="Connect Your Slack Workspace">
    1. Go to statusfield.com/integrations
    2. Click the Slack card
    3. Click Connect Slack button
    4. Select your Slack workspace
    5. Click Allow to grant Statusfield permissions

    <Callout variant="info" title="Permissions">
    Statusfield requests permission to:
    - View channel names and topics
    - Post messages to channels you select
    - No access to message history or DMs
    </Callout>

  </Step>

  <Step title="Add a Channel">
    After connecting:
    1. Click Add Slack Integration button in the manage drawer
    2. Select "Add Channel" option
    3. Select desired channel from the list
    4. Click Add Channel button
    5. You can edit the channel name later in the manage drawer

    You can add multiple channels and configure each one independently.

  </Step>

  <Step title="Test It Out">
    1. Click the menu (⋮) next to your Slack integration
    2. Select the Test action
    3. Check that the test message appears in your Slack channel

  </Step>

  <Step title="Configure Notifications">
    When adding a monitor for a service:
    1. Go to statusfield.com/notifications
    2. Find the service in the list
    3. Configure when you want to receive notifications (status by column)
      - On any status change
      - On maintenance status
      - On degraded status
      - On major outage status
      - On partial outage status

    A destination alerted about an incident also receives its recovery while the destination and alert rule remain active. Use Recovery only for destinations that only need the all-clear.

  </Step>

</Steps>

Quick Start: Slack Webhooks

<Steps>
  <Step title="Create a Slack Webhook">
    In your Slack workspace:
    1. Go to https://api.slack.com/apps
    2. Click Create New App > From scratch
    3. Name it "Statusfield" and select your workspace
    4. Navigate to Slack Features > Incoming Webhooks and toggle it on
    5. Click Add New Webhook
    6. Select the channel
    7. Copy the webhook URL (starts with https://hooks.slack.com/...)
  </Step>

  <Step title="Add Webhook to Statusfield">
    1. Go to statusfield.com/integrations
    2. Click the Slack card
    3. Click Add Slack Integration button
    4. Select "Slack Webhook" option
    5. Enter a name (e.g., "#engineering-alerts")
    6. Paste the webhook URL
    7. Click Add Webhook button

  </Step>

  <Step title="Test It Out">
    1. Click the menu (⋮) next to your Slack integration
    2. Select the Test action
    3. Check that the test message appears in your Slack channel

  </Step>

</Steps>

Slack Message Format

Each Slack notification includes:

- Service name - Clear identification (e.g., "🔴 GitHub")
- Status level - Current status with emoji indicator
  - 🟢 Operational
  - 🟡 Degraded
  - 🟠 Partial Outage
  - 🔴 Major Outage
  - 🔵 Maintenance
- Affected components - List of impacted components
- Status-change context - Details available for the detected update; vendor incident information is included when available
- Link - Button linking to full incident details on Statusfield

Managing OAuth Connections

View Connected Workspace

In the Slack integrations drawer, you'll see:

- Connected workspace name (e.g., "Connected to Acme Corp workspace")

Disconnect Workspace

To disconnect your Slack workspace:

1. Open statusfield.com/integrations > Slack
2. Click Disconnect next to the connected workspace
3. Confirm the action

<Callout variant='warning' title='Warning'>
  Disconnecting removes all OAuth channels and their notification rules.
  Everything is deleted. Webhooks are not affected.
</Callout>

Reconnect After Disconnection

If you disconnected or revoked access:

1. Click Connect Slack again
2. Authorize the workspace
3. Re-add your channels

Your previous notification configuration won't be restored automatically.

Choose the updates your channel needs

For a deployment channel, add GitHub and open its Overview from Monitors. Under Monitored components, choose Add or remove (or Pick components for an empty selection), switch to Only the components I choose, select Actions, and click Save. Then assign the relevant notification rules to that channel. Component availability varies by vendor. Keep your application monitoring and incident runbook alongside reported vendor status.

A labeled test confirms delivery to this destination; it is not a vendor incident. Check the channel itself after sending the test. Review the engineering workflow or quickstart for the full setup path.

Troubleshooting

- App approval required: ask a Slack workspace administrator to approve the installation.
- Private channel missing: invite the Statusfield app to the channel. Reconnect if the token predates private-channel permissions.
- Test fails: confirm the integration is active, check the displayed error, and retry after correcting the connection or webhook.
- Test arrives but incident updates do not: verify the monitor's notification rules, selected components, active plan and allowed channel. There may be no matching status change.

<Callout variant="warning" title="Not Receiving Slack Notifications?">
  Common issues and solutions:

1. OAuth Connection Expired

- Go to statusfield.com/integrations > Slack
- Click Connect Slack button
- Reauthorize the workspace

</Callout>

Security & Privacy

Permissions

Statusfield's Slack app requests minimal permissions:

- channels:read - View public channel names
- groups:read - View private channel names (if invited)
- chat:write - Post messages to selected channels
- channels:join - Join public channels used for notifications

We never access:

- Message history or content
- Direct messages
- Files or attachments

Data Protection

- OAuth tokens are encrypted in our database
- Tokens are only used to post notifications, nothing else
- Webhook URLs are stored securely
- All Slack API calls use HTTPS

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Receive service status notifications in your Slack workspace

Slack

Receive configured status alerts in a personal Telegram chat or a shared group. Statusfield connects through its own Telegram bot, so there is nothing to self-host and no bot token to manage.

<Callout variant='info' title='Plan Availability'>
  Telegram is available on paid plans. See the pricing page for
  current availability, or open the Telegram card on your integrations
  page to check whether it's included in
  your plan.
</Callout>

Quick Start

<Steps>
  <Step title="Add a Telegram Integration">
    1. Go to statusfield.com/integrations
    2. Click the Telegram card
    3. Give it a Name (e.g., "Ops group")
    4. Click Continue
  </Step>

  <Step title="Connect Your Chat or Group">
    Choose where alerts should go:

    - Connect personal chat — opens the Statusfield bot in your own Telegram DM
    - Connect a group — lets you pick a group to add the bot to

    Tap the button, then tap Start (for a group, confirm adding the bot). Statusfield links the chat automatically.

    <Callout variant='warning' title='The link expires in 15 minutes'>
      The connect link is valid for 15 minutes. If it lapses before you tap
      Start, reopen the integration and start the connect step again.
    </Callout>

  </Step>

<Step title='Confirm the Connection'>
  Once you tap Start, the integration flips to Connected and names the
  chat it linked (e.g., "Connected to Ops group"). You're done.
</Step>

  <Step title="Configure Notifications">
    When adding a monitor for a service:
    1. Go to statusfield.com/notifications
    2. Find the service in the list
    3. Choose which status changes should notify you (any change, degraded, partial outage, major outage, maintenance)

    A destination alerted about an incident also receives its recovery while the destination and alert rule remain active. Use Recovery only for destinations that only need the all-clear.

  </Step>
</Steps>

<Callout variant='info' title='Changing the Chat'>
  Each Telegram integration is linked to one chat. To deliver alerts to a
  different chat or group, remove the integration and add a new one.
</Callout>

Message Format

Each Telegram message includes:

- Service name and a status emoji (🟢 Operational, 🟡 Degraded, 🟠 Partial Outage, 🔴 Major Outage, 🔵 Maintenance)
- Affected components — the specific components impacted
- Timestamp — when the change was detected
- Link — a link to full incident details on Statusfield

Troubleshooting

<Callout variant='warning' title='Not Receiving Telegram Messages?'>
  Common issues and solutions:

1. The connect link expired

- The link is valid for 15 minutes. Reopen the Telegram integration and restart
  the connect step to get a fresh link.

2. Group members aren't seeing alerts

- Make sure the bot was actually added to the group when you tapped Start.
  If the group's privacy settings blocked it, remove and re-add the integration.

3. You want alerts somewhere else

- Integrations are one-chat-per-connection. Add a separate Telegram integration
  for each chat or group you want to notify.

</Callout>

Security & Privacy

- Statusfield only sends messages to the chat you explicitly connect.
- The bot never reads your chat history — it only receives the /start command that links the chat.
- The link code is single-use and short-lived (15 minutes).

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Get service status notifications in a Telegram chat or group

Telegram

Webhooks let you send HTTP requests to any endpoint when a monitored service changes status. Use them to trigger automations, update dashboards, create tickets, or integrate with any tool that accepts HTTP requests.

<Callout variant='info' title='Paid Plan Required'>
  Webhooks are available on the Starter, Pro, and Team plans. Upgrade your
  plan to get started.
</Callout>

Quick Start

<Steps>
  <Step title="Add a Webhook">
    1. Go to statusfield.com/integrations
    2. Click the Webhooks card
    3. Click Add Webhook
    4. Enter a name (e.g., "PagerDuty", "Jira Automation")
    5. Enter the webhook URL (must be HTTPS)
    6. Select the HTTP method (POST, GET, PUT, PATCH, or DELETE)
    7. Optionally configure authentication and custom headers
    8. Click Add Webhook

    <Callout variant="warning" title="HTTPS Required">
    Webhook URLs must use HTTPS. HTTP URLs are not accepted for security reasons.
    </Callout>

  </Step>

  <Step title="Configure Authentication (Optional)">
    If your endpoint requires authentication, select one:

    - None — No authentication header sent
    - Bearer Token — Sends Authorization: Bearer <your-token> header
    - Basic Auth — Sends Authorization: Basic <your-credentials> header

    Your authentication credentials are encrypted and stored securely.

  </Step>

  <Step title="Add Custom Headers (Optional)">
    You can add custom HTTP headers in JSON format:

    

  </Step>

  <Step title="Test It Out">
    1. Click the menu (⋮) next to your webhook integration
    2. Select Test Webhook
    3. Verify that your endpoint received the test request

  </Step>

  <Step title="Configure Notifications">
    When adding a monitor for a service:
    1. Go to statusfield.com/notifications
    2. Find the service in the list
    3. Configure when you want to receive notifications (status by column)
      - On any status change
      - On maintenance status
      - On degraded status
      - On major outage status
      - On partial outage status

    A destination alerted about an incident also receives its recovery while the destination and alert rule remain active. Use Recovery only for destinations that only need the all-clear.

  </Step>

</Steps>

Webhook Payload

When a status change occurs, Statusfield sends a JSON payload to your endpoint. Here's the full structure:

Payload Fields

| Field                    | Description                                                            |
| ------------------------ | ---------------------------------------------------------------------- |
| id                     | Unique delivery identifier                                             |
| event                  | Always "statuschange"                                               |
| level                  | "service" for top-level changes, "component" for component changes |
| service                | Service name, slug, and last check time                                |
| component              | Affected component with current and previous status                    |
| affectedComponents     | Array of child components that changed                                 |
| statusChange.direction | "worsening", "improving", or "unchanged"                         |
| statusChange.timestamp | ISO 8601 timestamp of the change                                       |
| url                    | Link to the service page on Statusfield                                |

Status Codes

| Status Code      | Human-Readable |
| ---------------- | -------------- |
| OPERATIONAL    | Operational    |
| DEGRADED       | Degraded       |
| PARTIALOUTAGE | Partial Outage |
| MAJOR_OUTAGE   | Major Outage   |
| MAINTENANCE    | Maintenance    |
| UNKNOWN        | Unknown        |

HTTP Methods

Choose the HTTP method that matches your endpoint:

- POST (default) — Standard for webhook receivers. Payload sent as JSON body.
- PUT — Payload sent as JSON body.
- PATCH — Payload sent as JSON body.
- GET — No request body sent. Use for simple ping-style endpoints.
- DELETE — No request body sent.

<Callout variant='info' title='Content-Type'>
  For POST, PUT, and PATCH requests, the payload is sent as application/json.
</Callout>

Delivery & Retries

- Notifications are sent within seconds of a status change
- Failed deliveries are retried up to 3 times with increasing delays
- Your endpoint should respond with a 2xx status code to confirm receipt
- Requests time out after 10 seconds
- HTTP redirects are not followed for security reasons

Use Cases

Webhooks are flexible enough for many integrations:

- Incident management — Create tickets in PagerDuty, Opsgenie, or ServiceNow
- Project management — Post to Jira, Linear, or Asana when services go down
- Custom dashboards — Feed status data into Grafana or Datadog
- Automation — Trigger Zapier, Make, or n8n workflows
- Internal tools: Update your own systems with detected status changes
- Chat tools — Send to Microsoft Teams, Telegram, or any chat with an incoming webhook

Managing Webhooks

Edit or Remove

1. Open statusfield.com/integrations > Webhooks
2. Click the menu (⋮) next to the integration
3. Select Edit to update the URL, method, authentication, or headers
4. Select Delete to remove the integration

<Callout variant='warning' title='Warning'>
  Deleting a webhook integration removes all associated notification rules. This
  cannot be undone.
</Callout>

Troubleshooting

<Callout variant="warning" title="Not Receiving Webhook Notifications?">
Common issues and solutions:

1. Endpoint Returns Non-2xx Status

- Your endpoint must return a 2xx status code (e.g., 200, 201, 204)
- Check your server logs for errors
- Verify the endpoint is accessible from the internet

2. HTTPS Certificate Issues

- Ensure your SSL certificate is valid and not expired
- Self-signed certificates may cause delivery failures

3. Authentication Errors

- Verify your Bearer token or Basic Auth credentials are correct
- Check that the authentication method matches what your endpoint expects

4. Timeout

- Webhook requests time out after 10 seconds
- Make sure your endpoint responds quickly — process the payload asynchronously if needed

5. Firewall or IP Restrictions

- Ensure your endpoint accepts requests from external sources
- Webhook requests originate from Cloudflare's IP ranges

</Callout>

Security

- All webhook URLs must use HTTPS
- Authentication credentials are encrypted in our database
- Custom headers are encrypted in our database
- HTTP redirects are rejected to prevent URL hijacking
- Each delivery has a unique id for deduplication

<Callout variant='info' title='Need Help?'>
  Contact our support team at
  support@statusfield.com
</Callout>

Send custom HTTP requests when service status changes

Webhooks

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and live data. Statusfield hosts a read-only MCP server for catalog search and recorded status from services your workspace monitors. Ask a compatible assistant questions like "Which of my monitored services are reporting problems?" The tools read existing records; they do not run a new probe or identify the cause of an application failure.

Requirements

The MCP server uses the same sf API key as the REST API — no separate credential. Create one at Integrations → API Keys, where you can also revoke it later. The key is shown only once at creation time.

<Callout variant='info' title='Starter plan and up'>
  MCP access is available on the Starter, Pro, and Team plans — the same
  gate as the REST API. It is not available on the Basic plan. A Basic-plan
  key returns 403 planrestriction. See
  /pricing for per-plan limits.
</Callout>

Connecting

The server speaks Streamable HTTP at POST /api/mcp and authenticates with your sf key in the Authorization header.

<Steps>
  <Step title="Get an API key">
    Go to Integrations → API Keys at
    statusfield.com/integrations and
    create a key. Copy it — it is shown only once.
  </Step>

  <Step title="Add it to the Claude Code CLI">
    Run the following, replacing sf<your-key> with your key:

    

  </Step>

  <Step title="Or connect another MCP client">
    Use your client's supported remote Streamable HTTP connection with URL
    https://statusfield.com/api/mcp and header Authorization: Bearer sf<your-key>.
    Client setup varies; use its documented remote-server settings. Do not paste
    your key into a prompt or a shared configuration.
  </Step>

  <Step title="Ask a question">
    Once connected, ask your assistant something like "Is GitHub having any
    issues right now?" for a service your workspace monitors. The assistant can use the matching tool; review the result before acting on it.
  </Step>
</Steps>

Tools

The server exposes three read-only tools:

| Tool                    | Input           | Description                                                                 |
| ----------------------- | --------------- | --------------------------------------------------------------------------- |
| searchservices       | query: string | Search the catalog by name; returns up to 10 matches as Name (slug) lines |
| getservicestatus    | slug: string  | Recorded status of a monitored service and its components                   |
| listmydownservices | (none)        | Your own monitored services currently down or degraded                      |

<Callout variant='warning' title='Catalog search vs. monitored status'>
  searchservices searches the public catalog without exposing status.
  getservicestatus returns status only for services your workspace actively
  monitors. listmydownservices reports your own monitors that are down or
  degraded. For the full monitor list, use GET /api/v2/monitors.
</Callout>

An empty problem list means no matching records were returned. It does not establish that every dependency or user workflow is healthy. MCP status text does not include observation timestamps; use the REST API or service detail page when you need to check freshness.

Rate limits & quota

- Rate limit: your plan's per-workspace burst limit applies to every request. X-RateLimit-Limit and X-RateLimit-Remaining are returned on responses, and a Retry-After (seconds) header is added on 429.
- Monthly quota: only tools/call invocations count toward your plan's monthly request quota. Protocol traffic (initialize, tools/list) is free. X-Quota-* headers are returned on metered requests, and exceeding the cap returns 429 quotaexceeded. The counter resets at the start of each UTC month.

Current limits, shared with REST per workspace:

<ApiPlanLimits />

Example prompts

Example questions and the tools an assistant can use:

- "Is GitHub having any issues right now?" → getservicestatus with slug github
- "Is anything I monitor down right now?" → listmydownservices
- "Find monitoring services" → searchservices with query monitoring

Next steps

- API reference — the full REST API, including GET /api/v2/monitors for your own workspace's monitors.
- Pricing — per-plan rate limits and monthly quotas.

Connect Claude and other AI tools to recorded status for your monitored services with the hosted MCP server. Read-only, Starter plan and up.

MCP Server

Start with the failure you want to hear about. Statusfield can follow a vendor's reported incidents, check your own website or API, and watch for missing check-ins from scheduled jobs. Choose a monitor, configure its rules, then test your alert destination.

Which monitor do I need?

| What you need to know                              | Choose                                        | What you configure                                                                      |
| -------------------------------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------- |
| Is a third-party service reporting an outage?      | Vendor monitoring       | The service, supported components or regions, and status changes you want to hear about |
| Is my website or API returning the right response? | Uptime monitoring       | A public HTTPS URL, response rules, check locations and frequency                       |
| Did my cron job, backup or sync finish its work?   | Heartbeat monitoring | A check-in after successful work, an expected interval and a grace period               |

These answer different questions. A green vendor status page can coexist with a failing website. A working website does not tell you whether last night's backup finished. Add the monitors that match your responsibilities; you do not need every type to get started.

Heartbeat availability follows the current access terms. For renewal reminders, use separate SSL certificate and domain expiry monitors.

Create your account and activate monitoring

1. Create an account using an available sign-in method. If you use email, follow the verification link in your inbox.
2. Choose the monitor types offered in setup, or choose Set up monitors later to continue to trial review. If you started from a vendor's alert form, check that the saved service is selected.
3. Configure each selected monitor type before trial review. Choose vendor components, enter your website or API settings, and set a heartbeat interval where access is available. For vendors, you can also review available incident history; an empty preview does not prove the vendor has never had an outage.
4. On Confirm & activate, review your selected plan, its trial terms, and its price after the trial.
5. Before activating, use Send test alert and check the inbox shown beside it. The message is labeled as a test. If sending fails, use Try sending again; check spam if a sent message is missing.
6. Activate the trial if eligible. Returning customers use their existing plan or choose a paid subscription. Successful setup opens Monitors with the monitors you configured. If you chose Set up monitors later, add your first monitor there. For a new heartbeat, open its Settings to get the check-in URL and send the first signal.

<Callout variant='info' title='A saved monitor is only the start'>
  Entering your email on a vendor page saves a pending choice. Verify your
  address and complete setup. The pending verification window is separate from
  the full trial; it does not provide a permanent free alerting plan. Continued
  monitoring after a trial requires a paid subscription.
</Callout>

See current plans and trial terms. You can manage your subscription and cancellation from billing settings.

Verify delivery after setup

To send another test after activation, open Integrations, find the destination, and use its test action. Check the actual inbox or channel: a successful request alone does not establish that everyone can see the message. An email test does not also verify Slack or Teams.

Receiving the test confirms that destination worked at the time of the test. Also check your monitor's notification rules: a destination test does not prove that a real failure will match those rules.

Choose relevant components and notifications

1. Open a service from Monitors to reach its Overview. Under Monitored components, choose Add or remove (or Pick components for an empty selection).
2. Choose Only the components I choose, select the components or regions your team uses from the options that provider exposes, then click Save.
3. Open Notifications and configure each monitor's destinations and status filters.
4. Verify each destination with a test. Recovery notifications follow the configured alert rules.

Vendor checks follow reported status changes. Update timing depends on the provider, polling, and delivery; a green vendor page does not rule out an account-specific issue.

Monitor your own website or API

An uptime monitor checks your URL directly, independently of the hosting provider's status report.

1. Open Create uptime monitor in your workspace. Give it a recognizable name, such as Production API, and enter a public HTTPS URL.
2. Open Advanced settings. Choose the expected status code or range, the response-time threshold for degradation, and the timeout. Add text or JSON response-body checks when a successful status code alone is not enough.
3. Select check locations and frequency. Each location uses one monitor unit; available choices depend on your plan.
4. Use Test now to inspect a response with your settings. This test runs from the app server; scheduled checks use your selected locations.
5. Choose notification destinations for degraded, outage and recovery events, then create the monitor. Review its recorded checks after creation.

For example, a health endpoint might need to return HTTP 200 and an expected JSON value. A valid but slow response can be degraded; an unexpected status, failed body rule or timeout is an outage. A successful HTTP check does not run a browser through a login or checkout.

Monitor a cron job, backup or sync

A heartbeat monitor waits for your job to contact Statusfield. It can notice a missing check-in even when the job never runs and cannot send its own error alert.

1. If heartbeat access is available in your workspace, open Create heartbeat monitor. Name the job, set its expected interval and allow a grace period for runs that finish late.
2. Choose destinations for missing check-ins or reported failures and for recovery. Create the monitor to get its private check-in URL.
3. Add that URL to the job after the work and your success checks finish. Keep the URL private; it contains the monitor's token.
4. Send the first successful check-in and confirm it appears in the monitor. Missing-check-in monitoring starts after the first signal, not merely when you create the monitor.
5. For a known job failure, call the same URL with /fail appended. Statusfield processes that failure without waiting for the expected interval and grace period to pass.

For a five-minute sync with one minute of grace, a check-in at 12:00 sets the next expected check-in at 12:05. If it is still missing after 12:06, the missed deadline can open an incident. Deadlines are evaluated every minute; alert delivery also takes processing time.

For a backup, check the backup command's result before sending success. Perform restore checks separately: a received ping does not establish that the archive is usable. See backup, inventory sync and report export examples.

Use a disposable test job to check the first signal, a missed deadline and recovery. Keep your production job running. The grace period tolerates lateness; it is not a maintenance calendar or a record of every expected run.

Watch the process that does your monitoring

If your own scheduler or health-check process fails, its silence can look like everything is fine. Have that process send a heartbeat after it completes its checks. Statusfield can then watch for a missed signal outside that process. Choose an alert destination that remains available when your monitored system fails, and test it.

For engineering teams

Start with a recurring responsibility: your production API, a nightly backup, or a dependency such as GitHub Actions. GitHub's vendor status describes the Actions service; a heartbeat from your own job describes whether that job checked in. Route each monitor's relevant updates to the people who can investigate.

- Engineering workflow
- Set up Slack alerts
- Set up PagerDuty
- Third-party outage runbook

For internal IT teams

Start with the business tools staff ask about. Route alerts to IT and create a board containing the monitors staff need to see. Share its link in your intranet or incident update.

- IT workflow
- Set up Microsoft Teams alerts
- Shared status boards

Unprotected boards are viewable by anyone with the link and do not grant workspace access. Include only services and labels you intend to share. Board features and limits depend on the plan. Adding an internal service means your team maintains its status manually.

If setup stops

- No verification email: check spam, then use the resend control when available. If a link expired, request a fresh link rather than repeatedly opening it.
- No trial available: trials are limited to eligible first-time customers. Check your existing subscription or choose a paid plan.
- Activation failed: read the message and retry using the activation control. A saved service selection alone does not mean alerts are active.
- Channel needs approval: ask your workspace administrator for the required installation permission, or use an available destination your team controls.
- Test arrives but no incident alerts: check that monitoring and the destination are active, the plan includes the channel, and notification rules include the relevant components and severity. There may have been no matching status change.

Choose a plan by workflow

Compare alert channels, sharing and reporting first, then confirm monitor and member capacity. Current limits and prices are listed below.

<PlansInfo />

Choose vendor, uptime or heartbeat monitoring, configure your first monitor, and test where its alerts go.

Quick Start Guide

Work with colleagues in a shared Statusfield workspace. Membership and available seats depend on the workspace owner's plan. See pricing for current limits.

Owners and members

Statusfield distinguishes the workspace owner from invited members. The owner manages invitations and membership; members can view the workspace member list and leave the workspace themselves. Billing is managed by the owner.

These are workspace roles. Team Access does not provide a configurable role builder or per-monitor permission settings.

Invite a colleague

1. Switch to the workspace you want to share.
2. As its owner, open Settings → Members.
3. Check available seats, enter your colleague's email address, and send the invitation.
4. Your colleague follows the invitation email and completes the acceptance flow. An invitation alone does not grant access.

Active invited members and pending, unexpired invitations both count toward the member limit. The owner is separate from that allowance. If seats are full, remove an unneeded member or revoke a pending invitation before inviting someone else, or review an appropriate plan.

Manage access

- Pending invitation: the owner can revoke it from the Members section. If it has expired, send a new invitation.
- Existing member: the owner can remove the member from the workspace after confirming the action.
- Leave a workspace: an invited member can use Leave workspace. The owner cannot remove themselves through this action.
- Switch workspaces: use the workspace selector to choose a workspace you belong to. Check the selected workspace before changing settings.

Share status without workspace membership

Use Status boards when people need a shared status view. Status board access and subscriptions are separate from workspace membership. Sharing a status board does not invite someone into your workspace.

Need help?

If an invitation fails, check the selected workspace, owner access, available seats and the error shown in the Members section. Contact support if you still cannot complete setup.

Share status without workspace membership