Pinga

Plain-English alarms

You know what matters.
Tell Pinga in your own words.

Describe the conditions that need attention. Pinga uses AI to interpret incoming messages against those instructions, then follows the notification settings you’ve chosen.

Create your first monitor ↗

Works with messages sent by email, SMS or webhook. No custom message parser required.

Three ways to put it to work

Your instructions.
The message.
A useful interpretation.

These illustrations show how context turns a routine reading or system message into an identifiable asset and issue. Try your own messages before enabling live notifications.

01 / TEMPERATURE LIMITS

A reading can be an alarm.

The equipment doesn’t have to use the word “fault”. Pinga can compare a reported temperature with the range you described, even if another status line says “OK”.

Example limits only. Choose appropriate thresholds and specify whether the boundaries themselves count as faults.

YOU DESCRIBE
“Raise a low-temperature alarm below 5°C and a high-temperature alarm above 10°C. Use the room name as the asset ID.”
THE MESSAGE ARRIVESCool Room 2
Air conditioner status: OK
Room temperature: 3°C
EXAMPLE INTERPRETATIONCool Room 2 · Low temperature

Fault: 3°C is below the 5°C lower limit.

02 / DEVICE CONNECTIVITY

Keep each device’s story straight.

Describe how your systems announce an outage and a recovery. Pinga identifies the asset and issue so NDD01 coming back online doesn’t clear an alarm for NDD02.

Aliases in your monitor instructions can help map different names to the same asset.

YOU DESCRIBE
“Monitor connectivity. Use the hostname as the asset ID. Lost connection or offline means a fault; connection restored means recovery.”
THE MESSAGE ARRIVESConnection to NDD01 has been restored.
EXAMPLE INTERPRETATIONNDD01 · Connectivity

Recovery for the matching connectivity issue. NDD02 is a separate asset.

03 / FAILED BACKUPS

Recognise the job that needs attention.

Give the monitor a clear scope. A backup failure and a connectivity fault on the same server are different issues and should keep separate histories.

Include the job name when several backup jobs need to be tracked independently.

YOU DESCRIBE
“Watch the nightly backup on SRV01. Report failure as a nightly-backup issue. A successful run recovers that same issue. Handle connectivity elsewhere.”
THE MESSAGE ARRIVESSRV01 — Nightly backup did not complete.
Destination unavailable.
EXAMPLE INTERPRETATIONSRV01 · Nightly backup

Fault: the monitored backup job failed.

A little context goes a long way

Write it like you’re
briefing a colleague.

  1. Define the scope.

    Which equipment or message types belong to this monitor? What should be handled elsewhere?

  2. Name the asset.

    Point to the hostname, room name, pump ID or another stable identifier in the message.

  3. Explain fault and recovery.

    Include the units, limits and wording that matter. Describe what a recovery for that same issue looks like.

  4. Test both the obvious and awkward cases.

    Try representative faults, recoveries, boundary values and incomplete messages. Check the interpretation and your notification sequence.

When a message isn’t clear

Keep uncertainty
visible.

If Pinga can’t confidently identify the monitor, asset, issue or meaning, the message needs a person’s review.

Shared SMS inputs use their Catch-all notification settings for uncertain matches. Messages sent directly to a monitor use that monitor’s notification settings when review is needed.

AI interprets the message it receives. It doesn’t independently measure the equipment or guarantee a correct reading. Keep your existing alarms and safety controls, and test the full path from message to response.

See how interpretation becomes a response ↗

Bring some order to the alarm.

Make the next
call-out a clearer one.

Get started with Pinga ↗Talk through your setup ↗

Start with one monitor.
Build the response around your team.