PingArkDocsQuickstart
Up and running

Quickstart

PingArk watches your scheduled jobs for silence. You create a check, you get a unique ping URL, and your job calls that URL each time it finishes. If a ping does not arrive on time, plus a grace window you choose, PingArk sends an alert. Getting started takes two steps.

# add this to the end of your cron job
curl -fsS https://pingark.com/ping/b3f1c2a8
Copy

The -fsS flags keep curl quiet on success and loud on a network error, so a failed ping never passes silently. That is all a healthy job needs to send.

Two ways to ping

Every check has two ping URLs, and they do exactly the same thing. Pick whichever reads better in your code. You can switch between them with the uuid and slug toggle on the check page, and the example snippets update to match.

# by UUID: opaque and unguessable
https://pingark.com/ping/b3f1c2a8-...

# by slug: readable, scoped to your project ping key
https://pingark.com/ping/your-ping-key/nightly-backup
Copy

Both URLs are secrets. Anyone who has one can ping the check, so keep them out of public logs. If a URL leaks, rotate it from the check settings and the old one stops working at once.

Ping types

A plain ping means success. Add a suffix to report something more specific. The same suffixes work on either URL form.

URLMeaning
/ping/<id>Success. Re-arms the deadline.
/ping/<id>/startThe run began. Lets PingArk measure how long it took.
/ping/<id>/failAn explicit failure. Alerts right away.
/ping/<id>/logA log entry. Records a note on the timeline, never alerts.
/ping/<id>/<exit>An exit code. Zero is success, anything else fails.

You can POST a body of up to 100 kB on any ping to attach logs or an exception trace. It shows up on the check timeline next to the ping.

History retention

PingArk keeps your ping history for a number of days that depends on your plan, from 30 days on Free up to a year on the largest plan. Each check also keeps up to a plan based number of its most recent events, so history is trimmed once it passes either the day window or that per-check event cap, whichever comes first. The cap only matters for very high-frequency checks, such as one pinging every few seconds, and it keeps storage predictable so we can offer long day based retention. Your downtime history is not affected by the per-check cap.

If you move to a smaller plan, we do not remove your older history straight away. Anything beyond the new plan window is kept for a 30-day grace period, so you have time to upgrade again or export what you need before it is removed.

The pricing page lists the days of history and the per-check event cap for every plan.

Schedules & grace

A check expects its next ping on a schedule, then waits out a grace window before it pages you. Set the grace to your job's normal run time plus a little headroom, so a slow run does not trip a false alarm. You can define the schedule three ways.

period · 1m to 365d cron · 0 2 * * * · UTC grace · 15m

Name, tags & notes

Give each check a clear name and a slug you control, which is the readable part of the ping URL. Add tags to group related jobs, then filter the checks board by tag to find them fast. When you start typing a tag, PingArk suggests the ones already used in your project so your labels stay consistent. A short description is handy too: it shows on the check page and rides along in your email and Slack alerts, so whoever gets paged has the context in hand.

Laravel plugin

If you run Laravel, this is the fastest path. Install the package and chain one method onto any scheduled command. The plugin wraps the run for you, sending a start and a finish, and capturing the duration, exit code, and any exception.

composer require pingark/pingark-laravel
Copy
// then in routes/console.php
Schedule::command('backup:run')->daily()->pingArk('nightly-backup');
Copy

Read the full Laravel plugin guide for the facade signals, exception capture, pingark:sync, and the management API client.

JavaScript & TypeScript SDK

Running scheduled jobs in Node, Next.js, Nuxt, or any JavaScript runtime? Install the pingark package and wrap a job in one monitor() call. It sends a start and a finish for you, and captures the duration, exit code, and any error.

npm install pingark
Copy
// then in your job
import { monitor } from 'pingark'
await monitor(() => runNightlyJob(), 'nightly-job')
Copy

Read the full JavaScript SDK guide for the signal helpers, the Next.js and Vercel Cron, Express, and Nuxt adapters, and the management API client.

Other languages

Anything that can make an HTTP request can ping a check, so PingArk works with any language or runtime. There are step-by-step guides for Shell and cron, Python, PHP, Node.js, Go, Ruby, PowerShell, .NET and C#, and GitHub Actions under Client libraries in the menu. Here are two quick examples to get the idea.

# Python
import urllib.request
urllib.request.urlopen("https://pingark.com/ping/b3f1c2a8")
Copy
# Ruby
require 'net/http'
Net::HTTP.get(URI("https://pingark.com/ping/b3f1c2a8"))
Copy

Filtering rules

Each check has optional filtering rules for when the world is messier than a clean ping. You will find them on the check page.

  • Accepted methods. By default a check accepts HEAD, GET, and POST. Switch it to POST only when bots or link-preview scanners hit the URL with a GET and file a false ping.
  • Content filtering. Match case-sensitive keywords in the POST body to mark a ping as a start, a success, or a failure. This is handy when a job always exits zero but writes "ERROR" to its output. If nothing matches, you choose whether to ignore the ping or treat it as a failure. An explicit /start or /fail in the URL is always honored.
  • Paused checks. Decide what a ping does to a paused check: resume it, which is the default, or ignore it and stay paused.

A ping that a rule drops still returns 200, so your job never errors or retries. It simply does not appear on the timeline.

Management API

Create, read, update, pause, and delete checks from your own code or CI, manage their tags, channels, and filtering rules, and pull back pings and status history. It is a REST API authenticated with a per-project key: a read-only key for dashboards and reports, a read-write key for automation.

GET /api/v1/checks
Authorization: Bearer pa_live_a1b2c3d4
Copy

Read the full API reference

Status badges

Embed a live SVG badge in a README. It reflects the current state and is cached at the CDN edge.

pingarkup

Read the full status badges guide for the project and tag scopes, the JSON and Shields.io formats, choosing the label, and rotating a badge URL.