tutorial

Sharry Monitoring with Vigilmon

"Learn how to monitor Sharry, the self-hosted file sharing web application, with Vigilmon — covering web application availability, file upload service health, database connectivity, S3/local storage backend health, share expiration job, email notification service, and download API response times."

Sharry Monitoring with Vigilmon

Sharry is a self-hosted file sharing web application built with Scala and the Play Framework. It runs on port 9090 and supports multiple storage backends (local filesystem or S3-compatible object storage), database backends (PostgreSQL, MariaDB, H2), and optional email notifications for share delivery. Teams use Sharry for secure internal and external file exchange — sharing documents, media, and binary files with colleagues or external partners via expiring share links.

Because Sharry handles both inbound and outbound file transfers with configurable expiration and email delivery, silent failures are particularly costly: uploads appear to succeed but files are not stored, email notifications are queued but never sent, and expiration jobs fail to clean up — all without alerting the sender.

This guide covers how to monitor Sharry with Vigilmon.

Why Sharry Needs Monitoring

Sharry failures break file sharing and can lead to data loss or storage exhaustion:

  • Play Framework application crash — the Scala/Play server stops responding; all share links return connection refused; uploaded files are inaccessible and new uploads are rejected
  • File upload service failure — the upload endpoint returns 500 or hangs; large file uploads time out; senders receive no meaningful error and believe the upload succeeded
  • Database connectivity failure — the PostgreSQL/MariaDB/H2 backend is unreachable or returns errors; Sharry cannot store upload metadata or retrieve share information; share links 404 even though files may be on disk
  • S3 or local storage backend failure — the configured storage backend (S3 bucket access denied, disk full, local path unmounted) returns errors; file bytes cannot be written or read; uploads appear to succeed but files are missing on download
  • Share expiration job failure — the background job that deletes expired shares stops running; expired share links remain accessible beyond their expiry date, and storage grows unboundedly
  • Email notification failure — the SMTP integration fails; share notification emails are not delivered; recipients are never informed that a file has been shared with them
  • Download API latency spike — large file downloads slow below acceptable thresholds due to I/O bottlenecks or storage backend degradation; recipients time out before receiving their files

Vigilmon monitors all of these failure modes so your team is alerted before a Sharry failure silently breaks file sharing.

Sharry Architecture Overview

| Component | Default Port | Role | Monitoring Priority | |-----------|-------------|------|---------------------| | Sharry (Play Framework/Scala) | 9090 | Web application, REST API | Critical | | PostgreSQL / MariaDB / H2 | 5432 / 3306 / embedded | Share metadata and user storage | Critical | | S3 or local filesystem | External / local | File byte storage | Critical | | Email (SMTP) | 25/465/587 | Share notification delivery | High | | Expiration cleanup job | Internal | Purge expired shares | High |

Monitor 1: Sharry Web Application Availability

Monitor the Sharry home page to confirm the Play Framework server is up:

  1. Log in to Vigilmon → Monitors → New Monitor
  2. Type: HTTP
  3. Name: Sharry - Web Application
  4. URL: http://your-sharry-host:9090/
  5. Method: GET
  6. Expected status: 200
  7. Keyword check: Sharry
  8. Interval: 1 minute

Test your endpoint:

curl -s http://your-sharry-host:9090/ | grep -i "sharry"
# Expected: HTML containing "Sharry"

Monitor 2: Sharry Health / Info Endpoint

Sharry exposes an OpenAPI-based info or health route. A 200 response confirms the Play application is routing and the database session pool is active:

  1. Type: HTTP
  2. Name: Sharry - Application Health
  3. URL: http://your-sharry-host:9090/api/info
  4. Method: GET
  5. Expected status: 200
  6. Keyword check: version
  7. Interval: 1 minute
curl -s http://your-sharry-host:9090/api/info
# Expected: JSON containing version and build info (HTTP 200)

If /api/info returns 404 for your Sharry version, fall back to checking the login page for HTTP 200 and a Sharry keyword.

Monitor 3: Sharry Upload API Availability

Monitor the upload endpoint to verify the file upload handler is active. An unauthenticated request returns 401, confirming the route is registered and the middleware chain is functioning:

  1. Type: HTTP
  2. Name: Sharry - Upload API
  3. URL: http://your-sharry-host:9090/api/upload
  4. Method: POST
  5. Expected status: 401
  6. Interval: 2 minutes
curl -s -o /dev/null -w "%{http_code}" \
  -X POST http://your-sharry-host:9090/api/upload
# Expected: 401 (unauthenticated — upload endpoint is functional)
# Error: 500 (Play application or database failure in the upload handler)

Monitor 4: Download API Response Time

Monitor the download endpoint response latency. Sharry downloads involve a database metadata lookup and a storage backend read — elevated response times indicate I/O bottlenecks in the database or storage layer:

  1. Type: HTTP
  2. Name: Sharry - Download API Latency
  3. URL: http://your-sharry-host:9090/api/open/share (list endpoint; returns 200 even if no public shares)
  4. Method: GET
  5. Expected status: 200
  6. Response time threshold: 3000ms
  7. Interval: 5 minutes
curl -s -o /dev/null -w "Total: %{time_total}s\n" \
  http://your-sharry-host:9090/api/open/share
# Alert if total time exceeds 3 seconds

Monitor 5: SSL Certificate Alert

If Sharry is exposed via a reverse proxy with HTTPS:

  1. Type: HTTP
  2. Name: Sharry - SSL Certificate
  3. URL: https://sharry.your-domain.com/
  4. SSL certificate expiry alert: 21 days before expiry
  5. Interval: 1 hour
curl -vI https://sharry.your-domain.com/ 2>&1 | grep "expire date"
# Expected: a future expiry date with at least 21 days remaining

Monitor 6: Sharry File Sharing Pipeline Heartbeat

An hourly end-to-end check that authenticates to Sharry, creates a share, uploads a test file, retrieves the download link, downloads the file, and verifies the content. This confirms the full pipeline — authentication, upload, storage write, metadata write, and download — is working:

Heartbeat Script

#!/bin/bash
# sharry-heartbeat.sh — run hourly via cron
set -euo pipefail

SHARRY_URL="http://your-sharry-host:9090"
SHARRY_USER="heartbeat@your-domain.com"
SHARRY_PASS="$SHARRY_HEARTBEAT_PASSWORD"
VIGILMON_HEARTBEAT="YOUR_HEARTBEAT_ID"
TEST_FILE=$(mktemp /tmp/sharry-test-XXXX.txt)

echo "sharry-heartbeat-$(date -u +%s)" > "$TEST_FILE"

# Step 1: Authenticate (obtain a bearer token)
AUTH_RESPONSE=$(curl -s -X POST \
  -H "Content-Type: application/json" \
  -d "{\"login\":\"${SHARRY_USER}\",\"password\":\"${SHARRY_PASS}\"}" \
  "${SHARRY_URL}/api/login")

TOKEN=$(echo "$AUTH_RESPONSE" | python3 -c "import sys,json; print(json.load(sys.stdin).get('token',''))" 2>/dev/null)

if [ -z "$TOKEN" ]; then
  echo "[sharry-hb] Authentication failed"
  rm -f "$TEST_FILE"
  exit 1
fi

# Step 2: Create a share
SHARE_RESPONSE=$(curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"heartbeat-share","validity":"P1D","maxViews":10}' \
  "${SHARRY_URL}/api/share")

SHARE_ID=$(echo "$SHARE_RESPONSE" | python3 -c "import sys,json; print(json.load(sys.stdin).get('id',''))" 2>/dev/null)

if [ -z "$SHARE_ID" ]; then
  echo "[sharry-hb] Share creation failed: $SHARE_RESPONSE"
  rm -f "$TEST_FILE"
  exit 1
fi

# Step 3: Upload a file to the share (verifies storage backend)
UPLOAD_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -F "file=@$TEST_FILE" \
  "${SHARRY_URL}/api/share/${SHARE_ID}/files")

if [ "$UPLOAD_STATUS" -ne 200 ] && [ "$UPLOAD_STATUS" -ne 201 ]; then
  echo "[sharry-hb] File upload returned $UPLOAD_STATUS (storage backend may be unavailable)"
  rm -f "$TEST_FILE"
  exit 1
fi

# Step 4: Publish the share
curl -s -o /dev/null -X POST \
  -H "Authorization: Bearer $TOKEN" \
  "${SHARRY_URL}/api/share/${SHARE_ID}/publish" || true

# Step 5: Download and verify
DOWNLOAD_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  "${SHARRY_URL}/api/open/share/${SHARE_ID}")

if [ "$DOWNLOAD_STATUS" -ne 200 ]; then
  echo "[sharry-hb] Share access returned $DOWNLOAD_STATUS for share $SHARE_ID"
  rm -f "$TEST_FILE"
  exit 1
fi

rm -f "$TEST_FILE"
echo "[sharry-hb] Auth, share creation, upload, and download all healthy"

# Step 6: Signal Vigilmon
curl -s "https://heartbeat.vigilmon.online/$VIGILMON_HEARTBEAT"

Add to cron:

# /etc/cron.d/sharry-heartbeat
0 * * * * root /opt/sharry/sharry-heartbeat.sh >> /var/log/sharry-heartbeat.log 2>&1

In Vigilmon:

  • Type: Heartbeat
  • Name: Sharry - File Sharing Pipeline
  • Expected interval: 1 hour
  • Grace period: 15 minutes

A missed heartbeat means the full sharing pipeline — which involves the database, storage backend, and Play application all working together — has failed.

Monitor 7: Email Notification Service (SMTP Heartbeat)

If Sharry is configured to send email notifications when files are shared, monitor the SMTP server availability to catch email delivery failures before senders realize recipients were never notified:

  1. Type: TCP
  2. Name: Sharry - Email SMTP Server
  3. Host: your-smtp-host
  4. Port: 587 (or 465 / 25 depending on your SMTP server)
  5. Interval: 5 minutes
# Test SMTP connectivity
nc -zv your-smtp-host 587
# Expected: Connection succeeded

For SMTP servers using STARTTLS or SMTPS, configure Vigilmon's TCP monitor with TLS validation enabled.

Alert Configuration

| Monitor | Type | Interval | Alert Channel | |---------|------|----------|---------------| | Web application | HTTP | 1 min | Slack + Email | | Application health | HTTP | 1 min | PagerDuty + Slack | | Upload API (401 check) | HTTP | 2 min | Slack | | Download API latency | HTTP | 5 min | Slack | | SSL certificate | HTTP | 1 hour | Email (21-day lead) | | File sharing pipeline | Heartbeat | 1 hour | PagerDuty + Email | | Email SMTP server | TCP | 5 min | Slack |

Use PagerDuty for the application health and heartbeat monitors. A database or storage backend failure in Sharry means files that appear uploaded are not actually stored — recipients receive 404s when they try to download, and the sender has no indication anything went wrong.

Status Page

  1. Status Pages → New Page → name it "Sharry File Sharing Service"
  2. Add all monitors above
  3. Share with your team and any external partners who use Sharry for file delivery

When a recipient reports that a shared file link is not working, this status page lets the sender determine immediately whether Sharry itself is down versus a specific link issue.

Summary

Sharry is a multi-layer file sharing service where failures in the Play application, database, storage backend, or email service can all silently break sharing without alerting senders. Vigilmon monitors the full stack:

  • HTTP monitors for web application availability, application health with database connectivity, upload API, and download API latency
  • TCP monitor for SMTP email notification server availability
  • SSL certificate monitoring with a 21-day lead time for HTTPS deployments
  • Hourly heartbeat that authenticates, creates a share, uploads a test file, publishes, and downloads — confirming the full pipeline from upload to delivery is working

Get started at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles