Migrate your Opsgenie heartbeats before 5 April 2027
Opsgenie reaches end of life on 5 April 2027. On that date access ends, the REST APIs stop responding, and data you did not migrate is deleted. Atlassian's own path moves you to Jira Service Management or Compass — a fair answer if you ran on-call rotations there, and a large one if all you used were heartbeats. This page is the mapping for that second case: every Opsgenie heartbeat setting, and what it becomes in LastPing.
Opsgenie retirement timeline: end of sale was 4 June 2025 — Opsgenie can no longer be purchased by new customers. End of life is 5 April 2027: access is shut off, the REST APIs stop responding, and any data not migrated by then is deleted. Atlassian provides an automated migration to Jira Service Management or Compass, and lets you run Opsgenie in parallel for 120 days afterwards to check the result. Dates are Atlassian's published timeline — confirm them on Atlassian's migration page before you plan around them.
Whether you should be on this page at all
Opsgenie was a well-regarded on-call platform that happened to include heartbeat monitoring. The retirement is an Atlassian strategy decision, not a verdict on the product. What matters for your migration is which half of Opsgenie you actually used.
If you used the on-call half — rotations, escalation policies, who-gets-woken-at-3am, SMS and phone alerting — then LastPing is not your answer and you should take Atlassian's path to Jira Service Management or Compass, or move to a dedicated on-call tool. LastPing has routing rules but no on-call schedules and no phone or SMS alerting. Saying otherwise would waste your migration window.
If you mostly used heartbeats — a handful of cron jobs and background tasks pinging a URL so somebody hears about it when they stop — then you are being moved onto a much larger product for a feature you barely used. That is the case this page is for. The mechanism is the same on both sides: your job calls a URL when it finishes, and an alert fires when the call stops arriving. Migrating is a URL swap, and the settings map one to one.
Feature by feature
What Opsgenie heartbeats offered, and what you get with LastPing.
| Capability | LastPing | Opsgenie Heartbeats |
|---|---|---|
| Product status | ✓ Active — under development | ✗ EOL 5 Apr 2027 — access ends, APIs stop responding, unmigrated data deleted |
| Free tier monitor cap | ✓ No cap — unlimited monitors free | ◐ Included in Opsgenie plan (which is EOL) |
| Cron / heartbeat monitoring | ✓ Curl a ping URL; cron or simple-interval schedules, grace windows, time zones | ✓ Same GET-request mechanism — your job pinged a URL on completion |
| CI/CD pipeline monitoring | ✓ Included free — one signed webhook (GitHub Actions, GitLab CI, Jenkins), zero YAML | ✗ Heartbeat-only — no CI/CD pipeline integration |
| CI/CD failure-reason detail | ✓ Deep link to the run + optional failing-step log excerpt on the incident, free | ✗ Not applicable |
| Agent-first MCP server | ✓ 36 MCP tools — an agent can create, instrument and silence its own monitors | ✗ |
| HTTP / uptime probing | ✓ Status code, latency, keyword checks | ✗ Heartbeat-only |
| Alert channels | ◐ Nine destinations — email, Slack, Discord, Telegram, signed webhook, ntfy, Pushover, Microsoft Teams, Google Chat. No SMS or phone. | ✓ Rich on-call alerting was a core Opsgenie strength |
| Overrun detection | ✓ max_runtime_s — catches a run that started and took too long, not just one that never finished |
✗ A late heartbeat that eventually arrives looks like an on-time one |
| Stalled mid-run detection | ✓ step_timeout_s — report a step per stage and catch a run that stopped progressing |
✗ No visibility inside a run |
| Silence floor between runs | ✓ expect_every_s — catches a job that quietly stops reporting altogether |
✗ Interval only |
| Succeeded but did nothing | ✓ Output assertions — a successful run whose output fails a condition still opens an incident | ✗ A ping is a ping |
| Runaway or looping jobs | ✓ Metric guards — a ceiling on a number the job reports about itself | ✗ |
| Monitoring-as-code | ✓ Terraform provider — monitors, destinations, routes and templates in version control | ◐ REST API, and community Terraform coverage |
| On-call scheduling | ✗ Routing rules but no on-call schedules today | ✓ Full on-call scheduling — a core Opsgenie feature |
| Teams & multi-user | ✗ Single-user today (top roadmap item) | ✓ Full team and escalation support |
| Public status pages | ✓ Public status pages + embeddable badges, free | ✗ |
Migrate from Opsgenie heartbeats
The mechanism is the same on both sides: your job calls a URL when it finishes. Step one is the call itself, step two is the settings around it.
1 · Swap the call
curl -X GET "https://api.opsgenie.com/v2/heartbeats/<name>/ping" \
-H "Authorization: GenieKey <api-key>"
# after — LastPing (no auth header required)
curl -fsS https://ping.lastping.dev/<id>
No API key header — the monitor ID in the URL is the credential, so there is
no secret to rotate into your crontab. Signal failure explicitly by appending
/fail before your job exits non-zero, and mark the beginning
of a long run with /start so overruns can be caught.
2 · Map the settings
Every field on an Opsgenie heartbeat has a counterpart, with one difference worth knowing before you copy your intervals across.
| Opsgenie heartbeat | LastPing | Notes |
|---|---|---|
name |
Monitor name | Free text on both sides. |
interval + intervalUnit |
period_s |
Seconds rather than a number-plus-unit pair. A 30-minute heartbeat becomes period_s: 1800. |
| — (no equivalent) | grace_s |
The one real difference. Opsgenie alerts the moment the interval lapses, so people pad the interval itself. LastPing separates the two: set period_s to when you actually expect the ping and grace_s to how late is tolerable. If you padded your Opsgenie interval, un-pad it here. |
| Cron-shaped schedules | cron_expr + tz |
A job that runs at 03:00 daily can be expressed as a cron schedule with a timezone rather than a fixed period, so clock changes do not produce false alerts. |
enabled: false |
Pause monitor | Pause and resume, or snooze for a fixed window during planned maintenance. |
alertMessage |
Alert template | Custom body per event type with variables and a live preview, so a recovery notice can read differently from a failure. |
alertPriority / alertTags |
Routing matrix | Priority is expressed as where it goes rather than a label: route down and fail to the destinations that page you, recovery to the ones that do not. |
ownerTeam |
— (not yet) | LastPing projects are single-owner today. If team ownership is load-bearing for you, this is the gap to weigh. |
3 · Move them in bulk
Clicking through forty heartbeats is nobody's afternoon. Declare them instead — the Terraform provider covers monitors, destinations, routes and alert templates, so the migration is reviewable in a pull request and repeatable if you get a field wrong.
name = "nightly-etl"
period_s = 86400 # was interval: 24, intervalUnit: hours
grace_s = 1800 # the padding you used to bake into the interval
}
resource "lastping_route" "page_on_down" {
monitor_id = lastping_monitor.nightly_etl.id
destination_id = lastping_destination.oncall_slack.id
event_type = "down"
}
The same objects are available over the REST API, and over MCP if you would rather hand the whole migration to an AI agent and review what it did. Monitoring-as-code →
Questions people ask
Front-loaded answers — the most important fact first.
-
Is Opsgenie heartbeat being discontinued?
Yes. Atlassian is retiring Opsgenie as a standalone product. End of sale was 4 June 2025 and end of life is 5 April 2027 — on that date access ends, the REST APIs stop responding, and data you have not migrated is deleted. If you use Opsgenie heartbeats to monitor cron jobs or background tasks, migrate before then.
-
What is the best free Opsgenie heartbeat alternative?
LastPing is an Opsgenie heartbeat alternative that is free for individuals, with no monitor cap. It monitors cron jobs and scheduled tasks via a simple ping URL (the same mechanism as Opsgenie heartbeats) and additionally monitors CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins) via one signed webhook. Migration is a single URL change.
-
How do I migrate from Opsgenie heartbeats to LastPing?
Create a monitor in LastPing, then replace the Opsgenie heartbeat ping URL in your cron job with the LastPing ping URL. Both use the same GET-request mechanism — your job curls a URL when it completes, and the monitor fires an alert if it stops receiving pings. No library or code changes beyond swapping the URL.
-
When does Opsgenie support end?
End of life is 5 April 2027, and end of sale was 4 June 2025. After the end-of-life date the product is not merely unsupported — access is shut off, the REST APIs stop responding, and unmigrated data is deleted. Atlassian offers an automated migration to Jira Service Management or Compass, with 120 days of parallel running afterwards. Confirm the current timeline on Atlassian's own migration page before planning around these dates.
-
Does LastPing have CI/CD pipeline monitoring that Opsgenie lacked?
Yes. Opsgenie heartbeats covered cron and background task monitoring but had no native CI/CD pipeline integration. LastPing monitors GitHub Actions, GitLab CI, and Jenkins pipelines as first-class monitors via one HMAC-signed webhook — zero YAML changes — catching runs that fail, hang, or never start, with failure detail attached to the incident. GitHub Actions guide →
Migrate before 5 April 2027.
One URL change per heartbeat, and the settings map across as they are. Free for individuals, and the Terraform provider will do the whole set at once if you have more than a handful.