Skip to main content
A part of your app is a server process or a scheduled job that must keep running: your API, a worker, the outbox relay, a nightly import. Each part sends a small sign of life, a heartbeat, every 5 minutes. Heartbeats never count toward your monthly events, and they keep arriving when your limit is reached.

The Engine room

Go to Technical and open the card Engine room (“last 12 hours”). It needs a role that may see code: Owner, Admin, Agency or Viewer.
  • One row per part: a server instance that sends heartbeats, or a job from your app map with its name.
  • How often it reports, like “every 5 min” or “every hour”.
  • The last sign, like “last sign 2 min ago”, or “never reported”.
  • Twelve dots for the last 12 hours. A dot is empty if the part sent nothing in that hour.
  • A mark only when a part is late or silent.
  • At the top: how many parts are running, for example “3 of 4 running”.
If your app sent no heartbeat yet, the card says “No heartbeats from your app yet.” The overview shows only the sum in its footer: how many parts are alive and the last sign. See Overview.

Late and silent

After a restart or a deploy, the old instances are replaced. They do not count as an outage: “n replaced instances (restart or deploy) are not counted as an outage.”

A heartbeat is no proof of the whole app

The card Reachability and heartbeats keeps two statements apart:
  • Missing heartbeats are a monitoring gap, not an outage.
  • A confirmed outage needs a failed reachability check.
A heartbeat from your backend does not prove a working database behind it.

When a part goes silent

  • One part goes silent while the rest still sends: you get one email and a banner. It ends when the part sends again.
  • The whole app goes silent: a case opens, “Your app stopped sending heartbeats”. It closes by itself with the next heartbeat.
  • A scheduled job misses two periods: a case opens, for example “Job has not reported for 2 periods”. It closes when the job reports again. This runs in production only.
See Flows and journeys.

How scheduled jobs report

Your coding agent adds the heartbeat to each job it finds. There are three ways.
The job sends its heartbeat at the end of each run that worked:
See the JavaScript SDK or the Python SDK.
A heartbeat can carry a result: ok, error, or in_progress at the start. On the Setup page, a job is Working only after a run that worked, and Last run failed after a failed one. If a job really cannot send a heartbeat, Setup says “everydeck can’t watch this job” instead of waiting for data.

Schedules outside your app

For a job in GitHub Actions, add two things at GitHub, for your repository:
  • the secret EVERYDECK_SERVER_KEY,
  • the variable EVERYDECK_URL.
Setup shows this as the part Heartbeat key at GitHub Actions. Your agent never sets them. The workflow ends with this step:
A check-in with a revoked key never fails your workflow. The check-in accepts only a job from your approved app map.

When you remove everydeck

Every schedule gets its own command back before everydeck removes the outbox. If that is not safely possible, everydeck removes nothing and names the schedule. See Removing everydeck.

What there is not

  • No history longer than 12 hours.
  • No parts without an SDK heartbeat.
  • A failed job run opens no case of its own. Only a silent job does.