---
title: Status check-in
description: Tell the status page a scheduled job ran, so a job that stops running turns its component red.
order: 4
---

Feature: `status`.

Some work is only visible when it stops: a nightly backup, an export, a sweep. A
**passive component** on the status page expects a check-in within a window, and turns
red when none arrives. `StatusCheckin` sends that check-in.

## Before you start

An ops administrator adds the passive component on the status page, with a slug (for
example `bjarup-backup`) and how long it may stay silent. The check-in token is a secret:
keep it in your secret group as `STATUS_CHECKIN_TOKEN`, beside `OPS_PUBLIC_URL`, the
address of ops (`https://ops.syncronet.dev`).

## Check in

```rust
use ops_sdk::status::StatusCheckin;

let checkin = StatusCheckin::from_env()?; // OPS_PUBLIC_URL and STATUS_CHECKIN_TOKEN
run_the_backup().await?;
checkin.checkin("bjarup-backup").await?;
```

Check in after the work succeeded, never before it: the point is that a failed run stays
silent.

Build the client once and keep it, because it holds a connection pool.
`StatusCheckin::new(ops_url, token)` takes both values directly when they do not come from
the environment.

## Errors

| error | meaning |
| --- | --- |
| `MissingUrl` | `OPS_PUBLIC_URL` is unset or empty |
| `MissingToken` | `STATUS_CHECKIN_TOKEN` is unset or empty |
| `Send` | the request did not reach ops |
| `Refused` | ops answered with an error status. Its own sentence is in the message: 401 is a wrong token, 404 a slug that is unknown or switched off |

The token travels in the `x-checkin-token` header, never in the URL, so it does not land
in an access log. The client's debug output hides it.