DEV Community: Pingvera.com

How to Tell a Client Their Website Went Down — Email and Status Update Templates

Pingvera.com — Tue, 01 Sep 2026 08:40:04 +0000

How to Tell a Client Their Website Went Down: Email and Status Update Templates

The first outage message does not need a root cause.

It needs four things:

acknowledgment;
known impact;
current action;
time of the next update.

Silence creates speculation. An overconfident explanation creates a second incident when it turns
out to be wrong.

Use the templates below before the outage, not while everyone is improvising.

Template 1: first notice

Subject: Investigating an issue with [website/service]

`Hi [Client name],

Our monitoring detected an issue affecting [website/service] at [time and timezone].

Known impact: [pages may be unavailable / forms may not deliver / checkout is failing].
We are investigating now.

We will send the next update by [time], even if the investigation is still in progress.

[Agency name]`
Do not wait for a full diagnosis. Atlassian's incident communication guidance recommends
acknowledging the issue, summarizing known impact, and promising the next update.

Template 2: investigation update

Subject: Update: [website/service] incident

`Hi [Client name],

The issue is still under investigation.

Current status:

[What is working]
[What remains affected]
[What the team is checking]

The root cause is currently [unknown / believed to be X but not yet confirmed].

Next update: [time and timezone].

[Agency name]`
Saying "root cause unknown" is better than omitting it and letting the client assume you forgot to
investigate.

Template 3: mitigation applied

Subject: Update: service restored, monitoring in progress

`Hi [Client name],

We applied a mitigation at [time]. [Website/form/checkout] is currently working again.

We are monitoring recovery and have not yet closed the incident.

Known impact:

Incident window: [start–current]
Affected function: [function]
Data or lead impact: [confirmed statement / still being assessed]

Next update: [time].

[Agency name]`
Do not say "resolved" immediately after pressing deploy. Confirm from the visitor perspective.

Template 4: resolution

Subject: Resolved: [website/service] incident

`Hi [Client name],

The incident affecting [function] was resolved at [time and timezone].

Impact:

Start: [time]
End: [time]
Affected function: [function]
Confirmed business impact: [facts only]

Resolution:
[One or two plain-language sentences.]

We are completing the incident review and will send [a final report / corrective actions] by [date].

[Agency name]`

Template 5: no confirmed client impact
Use this carefully. "No impact" must be supported.

`Our monitoring detected a brief regional failure from [region/provider]. Checks from other regions remained successful, and no customer-facing outage or form-delivery failure was confirmed.

The event is closed as a provider-specific monitoring incident. We will continue watching for recurrence.`
This is better than sending an alarming "site down" message and quietly retracting it later.

Status page versions

Status updates should be shorter than email.

Investigating

We are investigating failures affecting [service]. Some users may be unable to
[impact]. Next update by [time].

Identified

We identified the issue affecting [service] and are applying a mitigation. [Impact]
remains affected. Next update by [time].

Monitoring

Service has recovered after mitigation. We are monitoring stability before closing the
incident. Next update by [time].

Resolved

The incident was resolved at [time]. [Service] is operating normally. A summary will
follow for affected stakeholders.

What not to write

Avoid:

"Everything is broken."
"It is definitely the hosting provider" before confirmation.
"No data was lost" before verification.
"Should be fixed now."
raw stack traces;
internal blame;
promises with no next update.

Replace "should be fixed" with evidence:

Successful form submissions were confirmed from Frankfurt and Virginia at 11:03 UTC.
Monitoring will continue for 30 minutes.

Assign a communication owner

During a meaningful incident, the person diagnosing the system should not also be interrupted
every three minutes to rewrite client messages.

Assign:

incident owner;
technical lead;
communication owner.

For a small agency, one person may hold two roles. The roles should still be explicit.

Atlassian recommends a central source of truth, regular updates, and communication tailored to the
audience. External clients generally need short impact and recovery information, not every
technical branch of the investigation.

Choose one primary channel

Use one canonical location:

status page;
incident ticket shared with the client;
email thread;
client portal.

Other channels should point to it. This prevents email, Slack, and phone updates from contradicting
one another.

After the incident

Send a final report containing:

executive summary;
impact;
detection;
timeline;
contributing factors;
resolution;
corrective actions with owners and deadlines.

Then add the incident and completed corrective work to the monthly client report. The outage was
bad; a clear response can still strengthen trust.

Frequently asked questions

How often should clients receive updates?

Set the interval based on severity. For an active customer-impacting incident, Atlassian
recommends not going more than an hour without an external update and always stating when the
next update will arrive.

Should an agency call the client?

For severe business, security, or data impact, call the agreed emergency contact and follow
with a written record.

What if the client noticed first?

Acknowledge it directly, open the incident, and improve detection afterward. Do not argue
about timestamps while impact continues.

Sources

Originally published at pingvera.com.

Your client's site went down — how to know before they call you

Pingvera.com — Tue, 01 Sep 2026 08:40:03 +0000

Your client's site went down: how to know before they call you

Every minute of downtime means lost leads and orders for your client — and a dent in
your reputation as their contractor. The worst version is finding out about the outage from
the client themselves. Let's look at how to catch outages in minutes rather than hours,
without drowning in false alarms along the way.

“The site is down” is not one single state

Before you can catch an outage, it helps to understand that “not working” comes in very
different flavors — and a bare “server ping” misses half of them:

Complete unavailability — timeout, connection error, a 5xx from the server.
The “white screen” — the server returns 200 but the page is empty (a PHP fatal, a broken deploy). Technically “up”, practically not.
Hosting or database failure — the site loads, but with no data or with a DB error.
An SSL problem — the certificate expired or became invalid, and browsers block the way in.
A DNS failure or an unrenewed domain — the site doesn't resolve at all.
Degradation — the site is alive but takes 15 seconds to load; to a visitor that's almost the same as down.

Why you're the last to know

Three typical reasons you end up “hearing it from the client”:

You check by hand, irregularly. Nobody checks at night or on weekends.
You check from a single location. “It opens for me” doesn't mean it opens for everyone — the problem may sit with the hosting or the network.
You check the wrong thing. “The server responds to ping” ≠ “the site serves the right page”.

How to catch an outage in minutes

External checks on a short interval

The site should be polled by an external system — from the outside, like a regular visitor, and
continuously. Then you don't depend on your own computer or on “well, it opens for me”.
For critical sites it's also worth checking individual ports (TCP) and DNS records.

Check the right signal

The minimum is a 2xx status code and response time broken down by request phase. Better still — the
presence of key content on the page, to catch the “white screen” and content tampering. SSL and
domain expiry deserve their own watch: their “outages” are predictable and can be prevented ahead of time.

An instant channel straight to you

Detection is worthless if the signal never reaches you. The alert has to land where you'll see it
immediately — in Telegram or your email inbox. Then the gap between the outage and your reaction is
minutes, not “whenever the client calls”.

Alerts you can trust — not the boy who cried wolf

The number one reason people abandon monitoring is false alarms. A single network blip at 3 a.m.
wakes you for nothing, and a week later you've stopped reacting to alerts altogether.
Good monitoring confirms the problem before it wakes anyone:

Confirmation before the alarm — an alert only after several consecutive failed checks, not after a single blip.
Flapping suppression — if a monitor keeps bouncing up and down, its signal is muted so it doesn't flood you with notifications.
Maintenance windows — while you're updating the site, its alerts can be switched off in advance.
Auto-resolve and a timeline — when the site comes back, the incident closes itself, and the history keeps a record of when it went down and when it recovered.

How fast depends on the interval

Reaction time is the check interval multiplied by the number of failures required before the alarm.
Pingvera checks every 1 minute on every plan, including the free one — enough to know about an outage
before virtually any client does. Pick the sensitivity to match how critical the site is: an online
store needs an alert after the first confirmed minute, a brochure site can afford a gentler threshold.

Set it up once — across all your clients

Create an availability check for every client site, add SSL and domain-expiry monitoring — and keep it
all in one dashboard, grouped by client. Then an outage on any of your dozens of sites arrives as an
alert to you, and at the end of the month the client sees their uptime in a branded report.

Frequently asked questions

How fast does monitoring notice a site is down?

Speed depends on the check interval. Pingvera checks every 1 minute on every plan, including the
free one. Actual reaction time is the interval multiplied by the number of consecutive failed
checks required before the alert fires.

What if the site isn't down, just slow?

That's a separate state — degradation. Pingvera measures response time and can mark a monitor as
degraded based on a latency threshold, without waiting for a full outage.

How do I avoid false alarms at night?

An alert fires only after several consecutive failed checks, flapping monitors are suppressed,
and for planned work you can schedule a maintenance window so no alerts are sent.

Originally published at pingvera.com.

Ecommerce Conversion Rate Drop — A 60-Minute Diagnostic Playbook

Pingvera.com — Tue, 01 Sep 2026 07:00:20 +0000

Ecommerce Conversion Rate Drop: A 60-Minute Diagnostic Playbook

When ecommerce orders fall, first confirm the decline and identify the earliest funnel transition that changed. Work in order: data quality, demand, product discovery, cart, checkout, payment, order creation, OMS ingestion, and fulfilment.

The first hour is for narrowing the cause, limiting loss, and assigning owners. It is not the time to launch a redesign, replace the platform, or blame a vendor without evidence.

The first 60 minutes

0–10 minutes: validate the signal using two independent sources.
10–20 minutes: locate the first abnormal funnel step.
20–35 minutes: segment by device, region, channel, and payment method.
35–45 minutes: inspect recent changes and external dependencies.
45–60 minutes: enable a safe workaround, limit harmful traffic, and communicate facts.

Step 1: check whether sales or measurement failed

Compare at least two of:

storefront or OMS orders;
provider payment attempts and successes;
CRM leads;
analytics funnel events;
delivery emails or help-desk records;
server and application logs.

Orders present in the OMS but absent from analytics indicate a measurement problem. Successful payments without orders are a high-risk reconciliation incident. No payment attempts usually means the break is higher in the journey.

Step 2: find the first changed transition

Downstream metrics often fall because of the first broken transition. Start there.

Step 3: segment the impact

Check:

mobile vs desktop;
operating system and major browser;
region, currency, and language;
new vs returning customer;
paid, organic, affiliate, and direct traffic;
guest vs account checkout;
promotion vs standard pricing;
payment and shipping method;
product category;
experiment variant or storefront version.

“Safari checkout after release 4.8” is actionable. “Conversion is down 12%” is not.

Step 4: build a timeline

Include:

storefront and app releases;
tag-manager and consent changes;
CMS, plugin, or theme updates;
promotion and pricing rules;
carrier and shipping configuration;
product feed and inventory updates;
DNS, CDN, and certificate changes;
payment configuration;
campaigns and landing pages.

Time correlation is not proof, but it creates a shortlist of reversible, testable hypotheses.

Rapid hypothesis matrix

Decide what to do with paid traffic

If the purchase path is confirmed broken for everyone, pause traffic to it.
If one segment is affected, limit only the relevant devices, regions, or campaigns.
If a safe alternate route exists, change the destination and message.
If traffic quality is the cause, correct acquisition while healthy orders continue.
Record pause and restart times for the later analysis.

Avoid an automatic all-channel kill switch tied to one noisy metric.

Copyable hypothesis log

This prevents duplicate work and preserves evidence for the incident review.

After recovery

Confirm the journey with several marked tests.
Observe the funnel for an agreed window.
Reconcile payments and orders during the affected period.
Recover stuck operations safely.
Estimate business impact as a range.
Add a regression or journey check where safe.
Document root cause and systemic action.

Common mistakes

looking only at blended conversion;
trusting one analytics platform;
checking only the homepage;
changing several systems at once;
blindly retrying payment or order creation;
stopping all acquisition for a localised problem;
declaring recovery after one successful test;
skipping payment and order reconciliation.

FAQ

When is a conversion drop an incident?

When it is confirmed, materially affects a critical journey, and requires urgent coordinated action. Build the threshold from your baseline, volume, and contribution at risk.

How can I distinguish seasonality from a technical failure?

Compare genuinely similar periods and inspect funnel transitions. Demand changes often begin at the top; a technical regression commonly creates a sharp break at one step or segment.

Can synthetic tests place orders?

Yes, if they are clearly marked, financially safe, isolated from inventory and reporting, and cleaned up through an approved process.

Sources and further reading

Reviewed: 10 August 2026.

Next: payment-to-order reconciliation, critical journey monitoring, and the incident response playbook.

Pingvera can run revenue-journey checks continuously so a technical funnel break is visible before it appears only in daily sales reporting.

Originally published at pingvera.com.

Your Client's Status Page on Their Own Domain — CNAME Setup and Automatic TLS in Practice

Pingvera.com — Mon, 31 Aug 2026 08:40:03 +0000

Your Client's Status Page on Their Own Domain: CNAME Setup and Automatic TLS in Practice

A status page that lives at status.yourmonitoringvendor.com is a status page for your monitoring vendor. A status page at status.client.com is a deliverable — something the client sees, references, and associates with your work. The difference is a single DNS record and a few minutes of configuration. This checklist walks through the full setup: pointing a client subdomain to Pingvera, letting Pingvera handle TLS automatically, deciding whether the page is public or private, and adding the finishing touches that make it a proper retainer artifact.

Before you start: what you'll need

Access to the client's DNS (through their registrar, Cloudflare, or wherever their zone is managed).
A Pingvera account. Status pages are available on every plan; the custom domain (white-label) capability described here is part of the Pro plan.
A subdomain name agreed with the client. status.client.com is the convention most clients recognize immediately; uptime.client.com or health.client.com also work.

One note before touching DNS: Pingvera issues and renews the TLS certificate for the custom domain automatically, but it needs to verify domain ownership first — so the certificate can only be issued after the DNS change is live. The steps below are in the right order: you enter the domain in Pingvera first (to get the CNAME target), then create the record, then the certificate follows.

Step 1: Create the status page in Pingvera

In your dashboard, go to Status Pages and create a new page. Add the monitors you want to display — the client's main site, their contact form check, SSL expiry, domain expiry, or any combination that matches the retainer scope. Give the page a name the client will recognize: it appears in the browser tab and in subscriber notifications.

Step 2: Set the custom domain

In the status page settings, find the Custom Domain field and enter the subdomain you've agreed on — for example, status.client.com. Pingvera will show you a CNAME target: a hostname you'll point the subdomain to. Copy it exactly.

Step 3: Add the CNAME record in the client's DNS

Type: CNAME
Name / Host: status (or whatever subdomain prefix you chose)
Value / Points to: the Pingvera hostname from Step 2
TTL: 300 seconds is fine for initial setup; you can raise it later

DNS propagation is usually fast at a low TTL, but give it a few minutes before moving on.

Step 4: Let Pingvera issue the TLS certificate

Once the CNAME record resolves, Pingvera detects it and issues a TLS certificate for status.client.com automatically. You don't generate a certificate, upload anything, or configure a renewal schedule — when the certificate approaches expiry, Pingvera renews it.

One thing to check: if the client's DNS is behind Cloudflare with the proxy (orange cloud) enabled, switch this record to DNS-only (grey cloud). A proxied CNAME can interfere with certificate issuance.

Step 5: Decide on access — public or password-protected

Public page: anyone with the URL can see it. This is the right choice for most clients — it signals transparency and lets their own customers check status without calling support.

Password-protected page: use it when the client prefers not to expose uptime data publicly (common for SaaS products and internal tools), or when you want a private page for the client's internal team. For protected pages the RSS feed, badge and widget are disabled, so the private status doesn't leak through side channels. Both options live under the same custom domain, and you can switch at any time.

Step 6: Use maintenance windows

Schedule a maintenance window for the monitors attached to this page — a banner appears on the status page automatically, showing the window's start and end time. During the window, down alerts for those monitors are suppressed, so planned work doesn't fire "site down" notifications at the client's subscribers. A small thing that prevents a disproportionate number of client calls during routine work.

Step 7: Add the finishing touches

SVG status badge — embed a live badge in the client's website footer or internal dashboard.
Embeddable JS widget — a small widget for the client's own site, showing current status inline.
RSS feed — for public pages; useful if the client's team already lives in a feed reader.
Visitor subscriptions — visitors opt in on the page and receive down / back-up notifications via Telegram or email. Self-service, which means fewer people contacting the client (and you) during an incident.

Step 8: Send the client the URL

This is the step agencies sometimes skip. Don't. Send the client status.client.com with a short note explaining what it shows, and point out they can subscribe for notifications. If you're producing a monthly white-label report, mention that the status page and the report are the same data presented two ways — a live view versus a record they keep.

The client seeing their own subdomain with a valid certificate and live monitoring data — that's a tangible retainer deliverable, visible proof that something is running on their behalf every minute of every day.

Quick reference checklist

Create the status page and attach the relevant monitors
Enter the custom domain in status page settings (Pro plan)
Copy the CNAME target Pingvera provides
Add the CNAME record in the client's DNS (DNS-only if Cloudflare)
Wait for propagation; TLS certificate is issued automatically
Set access level: public or password-protected
Schedule maintenance windows for planned work
Configure badge, widget, RSS and visitor subscriptions
Send the client the URL

If you're not yet monitoring the sites behind this status page, start with a free Pingvera account — no credit card, up to five sites, one-minute checks, status pages included. White-label custom domains come with the Pro plan.

Originally published at pingvera.com.

Ecommerce Operations Dashboard — A 12-KPI Template

Pingvera.com — Mon, 31 Aug 2026 07:00:38 +0000

Ecommerce Operations Dashboard: A 12-KPI Template

An ecommerce operations dashboard should connect demand, conversion, order economics, and the ability to fulfil the customer promise. Every KPI needs a written definition, source of record, named owner, expected range, and action threshold.

If a chart cannot help the team decide what to investigate or change, it belongs in a diagnostic report rather than the main operating dashboard.

At a glance

Start with 12 signals:

qualified sessions;
add-to-cart rate;
checkout start rate;
orders created;
payment success rate;
orders fulfilled;
net revenue;
contribution margin;
new-customer CAC;
cancellation and return rate;
inventory and price freshness;
critical-journey success and detection time.

Show percentages and absolute impact: orders, contribution, customers, and minutes affected.

Why revenue alone is a late signal

Revenue tells the team what has already happened. Earlier signals reveal where intervention is possible:

qualified demand arriving;
item discovery and availability;
cart and checkout progression;
payment authorisation and confirmation;
order ingestion into the OMS;
fulfilment queue health;
inventory freshness;
critical journey availability.

A revenue decline can come from traffic mix, stockouts, mobile address validation, payment decline patterns, or a broken purchase event. One total cannot distinguish them.

Layer 1: demand

Do not judge demand by total sessions alone. A burst of low-intent traffic can reduce blended conversion while the store is healthy.

Layer 2: the commercial funnel

Record schema and checkout changes on the chart. A changed event definition can create a false business trend.

Layer 3: economics

Use the calculation in Ecommerce Unit Economics.

Layer 4: fulfilment and reliability

Copyable KPI contract

This contract prevents marketing from counting a browser event while finance counts settled funds without either side realising the definitions differ.

Set thresholds from your baseline

Collect 6–12 comparable weeks.
Segment major devices, regions, channels, and customer types.
Mark known incidents, promotions, and migrations.
Model expected ranges by weekday and hour where volume supports it.
Define a warning and incident threshold.
Back-test against known failures.
Review thresholds after a material journey or mix change.

Every alert should have an action. If the team ignores it repeatedly, improve the rule or remove the underlying noise.

Use three time horizons

Live operations

Minutes and hours: journey probes, checkout, payments, order queues, third-party latency, inventory age. Used by operations and on-call staff.

Weekly business review

Funnel, contribution, acquisition, fulfilment, and exceptions. Used to choose product, campaign, merchandising, and process actions.

Monthly and quarterly strategy

Cohorts, retention, channel contribution, unit-economics trends, platform risk, and investment. Do not crowd this view with probe-level noise.

A 45-minute weekly review

Start with KPIs outside their action thresholds.
Translate each variance into orders and contribution.
Separate demand, measurement, technical, and operational causes.
Select no more than three decisions.
Give each decision one accountable owner and deadline.
Record expected impact.
Open the next review with the result.

Worked scenario

Revenue is down 8% week over week even though sessions increased. The dashboard shows stable add-to-cart and checkout starts, but mobile payment success fell after an address-form release. The payment platform is otherwise healthy.

The appropriate action is to roll back the mobile change and add a journey test, not to redesign the catalogue or pause every campaign. The dashboard reduced a broad outcome to a testable cause.

Common mistakes

placing 50–100 metrics on the main screen;
percentages without absolute impact;
one blended conversion rate for every segment;
undocumented or changing definitions;
relying only on browser analytics;
no owner or required action;
monthly reporting for minute-level risk;
charts without releases, promotions, or incidents annotated.

FAQ

How many KPIs belong on the main dashboard?

Usually 8–12 decision-driving measures. Keep deep segmentation and diagnostics one level below.

What is the source of truth for sales?

Typically an OMS/ERP plus payment and finance reconciliation under an approved definition. Analytics explains behaviour and attribution but may miss or duplicate events.

Should uptime be included?

Yes, next to the success of real revenue journeys. Homepage availability does not prove that checkout, payment, and order delivery work.

Sources and further reading

Reviewed: 10 August 2026.

Next: diagnose an ecommerce conversion drop and audit analytics data quality.

Pingvera can supply the live reliability layer: critical-journey results, independent availability, detection time, and confirmed recovery.

Originally published at pingvera.com.

How to Calculate the Cost of Website Downtime

Pingvera.com — Sun, 30 Aug 2026 07:00:22 +0000

How to Calculate the Cost of Website Downtime

The cost of website downtime should be estimated from contribution margin and additional incident expense for the affected period, not simply average daily revenue. Include permanently lost orders or leads, acquisition spend sent to a broken journey, response and recovery work, compensation, manual reconciliation, and measurable downstream effects.

Distinguish a total outage from a broken checkout, one failed payment method, regional access, or degraded conversion. A site can return HTTP 200 while the business cannot sell.

At a glance

Use this first-pass equation:

Lost contribution = normal retained orders per minute × contribution per order × affected minutes × permanently lost share.

Then add:

wasted acquisition spend;
incident response and recovery cost;
compensation and operational rework;
downstream effects supported by cohort or customer data.

Present a low, working, and high scenario. False precision is less useful than an explicit range with evidence.

Define the failure mode

The calculation must follow the affected business journey.

Step 1: build a normal baseline

Compare the incident with genuinely similar periods:

same day of week and local time;
similar campaign and traffic mix;
comparable promotion and inventory state;
several historical periods rather than one;
segmentation by device or region when relevant.

Capture sessions, checkout starts, orders created, payments succeeded, orders retained, net revenue, contribution, and acquisition spend in 15-minute or appropriate intervals.

Step 2: use contribution, not gross revenue

A sale that never occurred does not consume all of its variable product and fulfilment costs. Use the contribution framework in Ecommerce Unit Economics.

Gross revenue may still be useful for communicating scale, but label it separately from estimated economic loss.

Step 3: separate lost, delayed, and shifted demand

Customers may:

abandon permanently;
return after recovery;
buy through an app, marketplace, store, or sales team;
submit a support-assisted order;
create a duplicate attempt.

Calculate the gross shortfall against baseline, then subtract verified late or channel-shifted orders. If the recovery share is unknown, show a range.

Step 4: add incident costs

Do not invent a large reputational number. Measure observable effects such as cancellations, repeat purchase changes in the affected cohort, complaints, or review volume.

Step 5: produce a range

Low case

verified contribution shortfall only;
documented additional costs;
recovered and shifted demand removed.

Working case

baseline-adjusted contribution shortfall;
evidence-based lost share;
acquisition, response, and compensation costs.

High case

plausible peak-period shortfall;
lower customer return rate;
extended recovery work;
uncertain downstream effects shown separately.

Worked example

A store normally retains 18 orders per hour in the affected window. Contribution per order is $34. Checkout fails for 40 minutes. Order IDs and later behaviour suggest that 45–65% of the missing demand did not return.

Estimated lost contribution:

low: 18 × 0.667 × $34 × 0.45 = approximately $184;
high: 18 × 0.667 × $34 × 0.65 = approximately $265.

Add $400 of acquisition spend and $1,200 of response and recovery work. The direct working range is approximately $1,784–$1,865.

These are illustrative values, not an industry benchmark.

Copyable impact card

Use cost to prioritise reliability

Estimate annual exposure:

Expected annual risk = incident probability × typical financial impact.

A hidden form failure that lasts a day several times a year may deserve more investment than a rare five-minute homepage outage. Use the calculation to set journey-monitoring frequency, severity, failover priorities, ad-pausing rules, and load-test budget.

Common mistakes

multiplying daily gross revenue by outage hours;
assuming every missing order is permanently lost;
ignoring partial or regional failures;
inventing an unsupported reputation cost;
comparing a campaign peak with an ordinary day;
including duplicate or test orders;
forgetting acquisition and reconciliation work;
drawing a precise conclusion from broken analytics.

FAQ

What if analytics failed during the outage?

Use OMS orders, payment attempts, CRM leads, server logs, ad spend, support records, and comparable periods. Widen the range and lower the confidence rating.

Should future customer lifetime value be included?

Only as a separate scenario supported by a credible cohort model and an identifiable affected group. Do not mix speculative lifetime value with verified direct loss.

How do I value downtime for a non-commerce site?

Choose a business unit such as a qualified lead, booking, document submission, activated user, or completed workflow. Estimate its contribution and how much demand can be recovered later.

Sources and further reading

Reviewed: 10 August 2026.

Next: build an ecommerce operations dashboard and define incident severity.

Pingvera provides independent incident timing, affected-journey evidence, and recovery confirmation for a defensible business-impact estimate.

Originally published at pingvera.com.

Send Pingvera Events to a Help Desk with Webhooks

Pingvera.com — Sat, 29 Aug 2026 07:00:14 +0000

Send Pingvera Events to a Help Desk with Webhooks

A reliable monitoring-to-help-desk integration creates one incident ticket for one confirmed failure, updates that ticket as evidence or severity changes, and resolves it only after confirmed recovery. It should not create a new ticket for every failed probe or webhook retry.

Use an HTTPS ingress, authenticate and persist the raw event, process it asynchronously, normalise fields into an agency-owned schema, deduplicate deliveries, map the incident to a ticket, and monitor the adapter itself.

Pingvera
↓ HTTPS webhook
ingress: authenticate, limit, persist
↓ durable queue
normalise + deduplicate + correlate
↓ routing/severity policy
Jira Service Management / Zendesk / Freshdesk / other help desk
↳ create, update, comment, resolve

Important implementation limitation
As of this article's review date, this workspace does not contain a public authoritative Pingvera webhook payload and signature specification. Therefore this guide does not invent product fields or headers.

Before implementation:

create a controlled test endpoint;
send each available Pingvera test event;
capture the exact raw body and permitted headers securely;
verify current authentication, signature, event types, delivery IDs, retries, and ordering in the product or official documentation;
map the real payload into the internal schema below.

The JSON examples are vendor-neutral internal contracts, not Pingvera API promises.

At a glance

Decide which confirmed events should create tickets.
Build an authenticated HTTPS endpoint.
Persist before acknowledging receipt.
Respond quickly and process asynchronously.
Reject unexpected event types and oversized payloads.
Deduplicate by verified delivery/event ID or a documented fallback.
Correlate one active incident to one ticket.
Treat failure, escalation, recovery, and reopen as state transitions.
Retry temporary help-desk errors safely.
Use a dead-letter queue and visible operator workflow.
Keep a second P1 notification route.
monitor ingress, queue age, worker errors, and API limits.

Define business rules first

Do not let the webhook receiver invent business severity from one HTTP status. Use site class, journey, confirmation, scope, workaround, time, and current maintenance state.

Why an adapter is necessary

Different data models

Monitoring describes checks and states. A help desk expects client, service, queue, priority, summary, description, assignee, and lifecycle.

Delivery retries and duplicates

Networks and providers retry. The receiver must safely process the same delivery more than once.

Ordering

Do not assume events always arrive in order. Store event time and allow only valid transitions.

Help-desk outage

An event must not disappear because the ticket API returns 429 or 503.

Security

The endpoint is public infrastructure and must resist forgery, replay, oversized bodies, secret leakage, and abuse.

Secure ingress

Prefer a provider-supported HMAC signature over the raw request body, including a timestamp and delivery ID if Pingvera supports them. If not, evaluate documented alternatives such as a secret header, bearer/basic authentication, mTLS, provider-published IP ranges, or an integration gateway.

Controls:

HTTPS with certificate verification;
exact method and content type;
body-size and rate limits;
authentication before parsing expensive content;
constant-time signature comparison;
timestamp tolerance and replay detection;
secrets in a manager, not URL query strings;
redacted logging;
rapid 2xx only after durable persistence.

GitHub's official webhook guidance similarly recommends a webhook secret, HTTPS, delivery IDs, event filtering, quick response, and asynchronous processing. Apply the principles while following Pingvera's actual contract.

Durable inbox record

Store:

delivery_id
received_at_utc
raw_body_hash
event_type
signature_verification_result
safe_payload_reference
processing_state
attempt_count
last_error
ticket_system
ticket_id
incident_key

Sensitive raw bodies should have strict access, encryption, minimisation, and retention.

Internal normalised event

{
"schema_version": 1,
"delivery_id": "provider-delivery-id",
"event_id": "provider-event-id",
"event_time": "2026-08-08T10:15:30Z",
"event_type": "incident.confirmed",
"state": "failing",
"site_id": "WEB-0042",
"check_id": "lead-delivery",
"incident_key": "WEB-0042:lead-delivery",
"service_class": "A",
"severity": "P1",
"summary": "Lead delivery is failing",
"observations": {
"first_failure": "2026-08-08T10:13:05Z",
"regions": ["eu-west"],
"confirmation_count": 2
},
"links": {
"monitor": "https://example.invalid/replace-with-real-link",
"runbook": "https://kb.example/WEB-0042/lead-delivery"
}
}

Populate only fields supported by the captured event plus trusted inventory/policy data. Never trust a payload-supplied help-desk project or assignee without an allowlisted mapping.

Incident-to-ticket state machine

healthy
└─ confirmed failure → create/open
open
├─ repeated failure → update evidence if useful
├─ severity increase → escalate
├─ partial recovery → remain open
└─ confirmed recovery → monitoring
monitoring
├─ failure returns within window → reopen same incident
└─ stable window complete → resolve
resolved
└─ new independent failure → new incident/ticket

Define when a later failure is a reopen versus a new incident. The rule may use check ID, service, recovery window, and recurrence policy.

Ticket field mapping

Use the current official API of the selected help desk. Do not rely on field names from this table without verifying tenant configuration.

Idempotency and deduplication

Preferred order:

reject already processed verified delivery_id;
deduplicate logical event by event_id where defined;
correlate active incident by stable incident_key;
use the help desk's external ID/idempotency feature if available;
after timeout, query mapping before creating again;
store the ticket ID transactionally with the result.

Do not hash the complete body as the only incident key: changing timestamps can create a new hash for the same outage.

Retry policy

Classify errors:

2xx: success, record response;
400/422: schema or mapping defect → dead-letter, operator action;
401/403: credential/permission incident → stop aggressive retry and escalate;
404: project/ticket mapping may be stale → investigate;
409: possible idempotency/state conflict → reconcile;
429: respect Retry-After, back off;
5xx/network timeout: bounded exponential backoff with jitter, then dead-letter.

Treat a create-request timeout as indeterminate until you check whether the ticket exists.

Pseudocode

receive(request):
enforce_tls_method_type_and_size(request)
verify_authentication_over_raw_body(request)
reject_replay_or_expired_timestamp(request)

if inbox.has(request.delivery_id):
return 200

inbox.persist(request.delivery_id, raw_body, safe_headers)
queue.enqueue(request.delivery_id)
return 202

worker(delivery_id):
event = normalise(inbox.load(delivery_id), trusted_inventory)
validate_schema_and_allowlisted_mapping(event)

incident = incidents.find_active(event.incident_key)
action = state_machine.decide(incident, event)

result = helpdesk.apply_idempotently(action)
persist_mapping_and_result(result)

Monitor the integration
Alert on:

webhook authentication failures;
ingress 5xx and latency;
queue depth and oldest message age;
normalisation/mapping failures;
help-desk authentication and rate limits;
dead-letter messages;
incidents without ticket mapping;
tickets still open after confirmed recovery;
no test event received within the expected validation period.

Test the route periodically with a clearly labelled synthetic event that cannot be mistaken for a live client incident.

P1 fallback

The help desk and adapter can fail during the same broad provider incident. A P1 should retain an independent route—phone, pager, SMS, or another approved channel. The ticket is the work record, not necessarily the only alarm.

Common mistakes

webhook directly creates a new ticket every time;
acknowledging before durable persistence;
trusting project/assignee from unverified payload;
secrets in the endpoint URL;
signature validation after JSON re-serialisation instead of raw body;
no replay or duplicate protection;
retrying 401 forever;
resolving on the first healthy probe;
no mapping for maintenance windows;
adapter is not monitored;
code built against guessed Pingvera fields.

FAQ

Can n8n, Zapier, or Make replace the adapter?

They can be suitable for a low-criticality prototype if they support required authentication, persistence, deduplication, retries, data handling, and observability. Evaluate the failure model before routing P1 incidents.

Should every Pingvera alert create a ticket?

No. Confirm failures and map actionable risks. Retain raw observations without turning every probe into human work.

How should recovery close the ticket?

Move to a monitoring state after confirmed recovery, validate the agreed journey for an observation window, then resolve automatically or with human approval according to policy.

What if Pingvera does not provide a delivery ID or signature?

Use only documented authentication and a carefully designed fallback deduplication scheme. Raise the residual risk; do not invent headers. Ask Pingvera support for the current supported contract.

Sources and further reading

Reviewed: 8 August 2026.

Previous: Monitoring as code for web agencies. Return to the Academy overview.

Before publishing implementation code, capture the real Pingvera webhook contract and test it against the chosen help-desk API. The architecture in this guide is ready; product-specific field mapping must be evidence-based.

Originally published at pingvera.com.

A Client Report They Will Actually Read — One Page, Four Answers

Pingvera.com — Fri, 28 Aug 2026 08:40:04 +0000

A Client Report They Will Actually Read: One Page, Four Answers

Your client does not open a maintenance report because they are fascinated by uptime
percentages. They open it because they want reassurance — or because they suspect something is
wrong. If the first page does not answer that concern immediately, the report has failed before
the client reaches page two. The solution is not a prettier technical dashboard. It is a
different information hierarchy: the answer first, the evidence second.

The four questions on the client's mind

Every useful client report should answer:

Is everything under control?
What went wrong?
What did you do about it?
What happens next?

Most automated reports reverse that order. They start with update counts, backups, charts,
security scans, and version numbers. The client gets evidence without a conclusion.

An executive report gives the conclusion first and makes every technical section prove it.

Start with a sentence, not a score

A score such as "Website health: 91/100" looks precise, but it hides the reason behind the
number. Is 91 good? Did checkout fail? Is the domain expiring? Did monitoring only cover three
days?

Use a status plus a sentence:

Needs attention. The website remained available, but the domain
expires in 18 days and should be renewed before July 25.

That is understandable, actionable, and traceable to facts.

Recommended states:

Under control
Needs attention
Action required
Insufficient data

"Insufficient data" is essential. Without it, missing monitoring quietly becomes a green
result.

Show outcomes, not tool activity

Clients buy outcomes:

the website was available;
leads arrived;
checkout worked;
critical pages remained indexable;
the domain and certificate stayed valid;
incidents were detected and handled.

They do not buy a count of how often your tool looked at those things.

Compare these two statements:

43,200 HTTP checks completed.

The website was available for 99.98% of the month. One 9-minute outage was detected
before the client reported it.

The first describes software activity. The second describes service value.

Give incidents a beginning, middle, and end

An incident row should contain:

what failed;
who or what was affected;
when monitoring detected it;
when service was restored;
whether anything remains open.

Avoid claiming a root cause unless it is confirmed. "The form failed after a deployment" is
evidence. "The deployment caused the failure" is a conclusion that may need investigation.

When the cause is unknown, say so. Honest uncertainty builds more trust than a polished
guess.

Make the agency's work visible

Automated monitoring cannot know everything your team did. Add a short work log:

Do not turn this into a timesheet unless the contract requires it. The client cares about the
result.

End with one decision

The final block should answer "What do you need from me?"

Good:

Approve the PHP upgrade before August 15. Owner: Client. Estimated downtime:
none.

Weak:

We recommend reviewing the website's broader technical architecture and considering
future optimization opportunities.

One owner. One deadline. One reason.

The one-page layout

Use this order:

Agency branding, client, site, period.
Overall status and explanation.
Four outcome cards.
Prevented or resolved problems.
Work completed.
Risk requiring attention.
One next action.

Put uptime charts, test history, server metrics, WordPress details, and raw incidents in the
appendix.

Design rules that matter more than decoration

Use plain language before technical labels.
Keep green sections compact; give more space to exceptions.
Never use color as the only status signal.
Show the reporting period and data coverage.
Distinguish zero from not configured.
Use the same definitions every month.
Freeze sent reports so live data cannot rewrite history.

A report is part of the service

Reporting should not be treated as paperwork added after maintenance. It is the client-facing
part of maintenance.

Without the report, your team knows what happened and the client does not. That information gap
is where "What are we paying for?" begins.

With a clear report, even a quiet month has a story:

No critical outages. Form delivery remained healthy. SSL and the domain are safe. Two
maintenance tasks were completed. No client action is required.

That is not fluff. That is the outcome the retainer was meant to produce.

Frequently asked questions

Should the report include every plugin update?

Not on the first page. Summarize the result and keep the detailed update list in the
appendix.

Should a client report include traffic?

Only if traffic acquisition is part of the service and someone is responsible for
interpreting the numbers.

Should reports be sent as PDF or a link?

Offer both when possible. A hosted report is easier to explore; an immutable PDF is useful
for records and forwarding.

Sources and further reading

Originally published at pingvera.com.

“Your site is down” — why “it works for me” is the worst answer a client can hear

Pingvera.com — Fri, 28 Aug 2026 08:40:03 +0000

“Your site is down”: why “it works for me” is the worst answer a client can hear

There's one phrase that makes every web agency's blood run cold: “Our site isn't working.” And if the agency learns about the outage from the client, it has already lost the first round — even if everything gets fixed ten minutes later. Let's break down why “it works for me” is the worst possible answer, and how to check website availability so you see the problem before the client does.

Why “Give us a second, we'll check” already sounds bad

The call usually skips the pleasantries: “What's going on over there? We're running ads. Customers can't get in. Are you even watching the site?” The natural reply is “Give us a second, we'll check.” But that phrase is already a losing move. The client doesn't hear “we're on it” — they hear “we had no idea.” They pay the agency partly for peace of mind, and instead they get the feeling that nobody is watching their site at all.

The worst thing you can say next: “It works for me.” The site doesn't open for the client. It opens for the account manager. It opens for the developer on mobile data. The hosting status page is all green. There are ten messages in the chat, and nobody actually knows: is the site down or not?

Checking from one laptop is a coin flip, not a diagnosis

The biggest mistake is assuming that “it works for me” disproves the problem. A site doesn't have to go down for everyone at once. What can fail on its own:

one region or one ISP;
one DNS resolver;
one CDN node;
only the www version of the domain, while the bare domain is perfectly fine;
the homepage responds, but the contact form and the cart are already dead.

That's why checking availability from a single device proves nothing. To know whether the site is down for everyone or only for some visitors, you need checks from several independent locations. From one network you see your network — not what the client sees.

What you need to know within the first two minutes

While the chat argues about “what about on your phone? try a VPN? send a screenshot”, a grown-up support team answers concrete questions:

Is the site down for everyone or only for part of the audience?
Where exactly is the failure — DNS, TLS, HTTP, the application, a redirect, or a timeout?
Is the whole site down, or a single page?
Is the failure confirmed by several checks, or was it one brief blip?
When was the last successful check?

Without those answers, every outage turns into a manual interrogation of the client. Sometimes you do need to ask follow-up questions. But if every incident starts that way, that's not support — that's a fire brigade wearing a blindfold.

A site can be “up” and still be killing the business

The reverse happens too: the site opens, uptime monitoring is green, the homepage returns 200 OK, everyone relaxes. And the client still gets no leads. Because the form doesn't send the email. Or the CRM rejects the lead. Or the thank-you page is broken. Or the catalog works while checkout is down.

The client doesn't need a site that merely “opens.” They need a site that does its job — brings in leads and orders. If monitoring only checks the homepage, it catches the crudest outages while the quiet business-function failures slip right past. That's why Pingvera doesn't stop at availability and request timing — it can also do a synthetic form submission and verify that the lead actually reached the inbox, instead of just “the page loaded.”

What grown-up availability monitoring looks like

Proper monitoring works like this:

the site is checked automatically, not “when someone remembers”;
checks run from several locations, not from one laptop;
at a sensible frequency — say, once a minute;
with failure confirmation, so nobody gets woken up by one random blip;
with a breakdown of what exactly failed: DNS, TLS, HTTP, a form, a redirect, a page, the CMS, or the server.

Then instead of a sheepish “let us check”, you can write the client a calm, precise message: “We can see an availability issue. The failure is confirmed from multiple locations and started at 10:42. We're checking the hosting and the network route.” That's the difference between “the client caught us napping” and “we're in control of the situation.”

Frequently asked questions

How do I check whether a site is really down, or just down for me?

Check availability from several independent locations, not from a single laptop. If the site fails to load only for you but responds fine from other networks and regions, the problem is local: your ISP, DNS resolver, browser cache, or VPN. A real outage shows up from several locations at once. Pingvera checks from multiple locations and opens an incident only on quorum — when the failure is confirmed, not on a single random blip.

Why does a website fail to load only for some visitors?

A site can be unavailable for part of its audience rather than everyone. One region, one ISP, one DNS resolver, or one CDN node can drop out. Sometimes only the www version of the domain fails while the bare domain is fine, or the homepage responds while the contact form and the cart are already down. That's why a check from one device proves nothing — you need availability checks from multiple locations and across different scenarios.

How can I find out quickly that a site went down?

You need automated uptime monitoring with frequent checks and alerts. Pingvera checks sites every minute on every plan, including the free one, confirms failures from multiple locations, and sends a notification to Telegram or email. That way the agency learns the site is down before the client does — not from their phone call.

Originally published at pingvera.com.

Monitoring as Code for Web Agencies — When and How

Pingvera.com — Fri, 28 Aug 2026 07:00:38 +0000

Monitoring as Code for Web Agencies: When and How

Monitoring as code means storing the intended monitoring configuration in a versioned, reviewable format and applying it through an API, CLI, provider, or controlled automation. It is useful when an agency has repeatable service classes, many similar client sites, frequent onboarding, and configuration drift that manual review can no longer control.

It is not automatically better for a ten-site portfolio with unstable standards. Automating inconsistent monitoring creates inconsistent monitoring faster.

At a glance

Use monitoring as code when the agency needs:

repeatable monitor bundles;
peer-reviewed changes;
history and rollback;
bulk policy updates;
drift and exception visibility;
automated onboarding/offboarding;
consistent routing and metadata.

Keep secrets outside the repository, test generated configuration, use canary rollout, and prevent automation from deleting or silencing production monitors without safeguards.

What belongs in code

service class and monitor template version;
URL/path, method, expected status/content, frequency, timeout;
safe synthetic request definition;
TLS/domain thresholds;
regions and confirmation logic;
severity, owner, client/site IDs, and alert route references;
maintenance-window reference;
exception ID and expiry;
help-desk/status-page mapping;
disabled state with reason and expiry.

Do not commit:

passwords, API tokens, private keys, mailbox credentials;
production customer data;
unredacted webhook samples containing sensitive information;
secrets hidden in URLs or request bodies.

A vendor-neutral internal schema

The following YAML is an agency-owned desired-state format, not a claim about Pingvera or another vendor's API.

schema_version: 1
site_id: WEB-0042
service_class: A
owners:
service: client-success
technical: maintenance-platform
alert_route: oncall-critical

checks:

id: canonical-home
type: http_content
url: https://shop.example.com/
interval_seconds: 60
timeout_seconds: 10
expected_status: 200
expected_text: "Shop Example"
regions: [us-east, eu-west]
confirm_after: 2
severity: P2
id: lead-delivery
type: form_delivery
form_url: https://shop.example.com/contact
interval_seconds: 300
payload_secret_ref: vault://clients/WEB-0042/form-test
destination_secret_ref: vault://clients/WEB-0042/test-mailbox
delivery_deadline_seconds: 180
severity: P1

expiry:
tls_days: [30, 14, 7]
domain_days: [60, 30, 14]

exceptions:

id: EX-019 check: lead-delivery reason: "Client migration window" expires_at: 2026-09-01T12:00:00Z approved_by: client-service-owner

Repository structure
monitoring/
├── schemas/
│ └── site-monitoring-v1.json
├── templates/
│ ├── class-a-store.yaml
│ ├── class-b-lead-site.yaml
│ └── class-c-content.yaml
├── sites/
│ ├── WEB-0042.yaml
│ └── WEB-0043.yaml
├── policies/
│ ├── alert-routes.yaml
│ └── maintenance-windows.yaml
├── tests/
│ ├── required-checks.yaml
│ └── fixtures/
└── README.md

Separate reusable templates from site parameters and explicit exceptions.

Change workflow

inventory change
→ generate/edit desired state
→ schema and policy validation
→ peer review
→ dry run / diff
→ canary apply
→ external validation
→ staged rollout
→ evidence and inventory update

Require human approval for high-blast-radius changes: deletion, mass disablement, alert-route changes, reduced frequency, weakened success condition, or changed P1 suppression.

Tests to run before apply

Schema tests

required fields and valid types;
valid URLs, time zones, UTC timestamps, and severity values;
unique site and check IDs;
exception expiry present;
no plaintext-secret patterns.

Policy tests

active Class A/B site has a critical journey;
P1/P2 route has a fallback;
suppression cannot exceed policy maximum;
domain/TLS thresholds meet the class standard;
form/checkout test has synthetic-data and cleanup metadata;
archived site cannot receive normal on-call routing.

Behaviour tests

monitor endpoint is reachable from test context;
expected marker is specific enough;
synthetic action cannot trigger a real charge/shipment;
test event reaches the correct route;
apply is idempotent;
deleted configuration requires explicit approval.

Drift and source of truth

Decide whether:

code is authoritative and UI changes are prohibited/reverted;
UI changes are imported into code through review;
selected fields are managed manually and ignored by automation.

Without a declared model, engineers will fight the tool: code overwrites emergency changes, while the UI creates invisible drift.

Emergency UI changes should create an incident/change record and a follow-up pull request.

Safe rollout

begin with read-only export and diff;
onboard a small representative portfolio;
apply one template change to canaries;
verify monitoring and alert delivery;
roll out in batches;
stop on unexpected deletion, route change, or alert spike;
retain a previous desired state and provider-side evidence;
review exceptions and drift after rollout.

Do not deploy a new monitor template to 100 sites at the same moment as a CMS bulk update.

API and automation reliability

respect rate limits and pagination;
use idempotent operations where supported;
persist provider IDs mapped to internal site/check IDs;
retry temporary failures with bounded backoff;
distinguish “request accepted” from “monitor active”;
reconcile desired and observed state;
log changes without logging secrets;
monitor the automation itself;
require explicit handling for partial bulk failure.

When not to use monitoring as code

portfolio is small and changes are rare;
service classes and required checks are not defined;
provider lacks a stable supported API/export;
nobody owns the repository and failed applies;
manual UI configuration is currently faster and fully reviewable;
automation risk exceeds current configuration drift.

A structured inventory and manual template checklist may be the correct intermediate stage.

Example: expired exceptions

An agency disables checkout monitoring during a client migration and forgets to restore it. In code, the exception requires an expires_at value. Policy validation fails if expiry is absent, and the reconcile job surfaces the expired exception even if the provider leaves the check paused.

The benefit is not YAML. It is an enforceable lifecycle for deviations.

Common mistakes

repository filled with copied full configurations instead of templates;
secrets committed in headers or URLs;
no dry run or destructive-change approval;
code and UI both treated as authoritative;
assuming API success means check success;
bulk rollout without canaries;
no owner for failed or partial applies;
automating before defining service classes;
measuring lines of configuration instead of coverage and alert quality.

FAQ

Is Terraform required?

No. A supported provider, CLI, API client, GitOps workflow, or internal reconciler can implement the pattern. Choose the least complex reliable option.

How many sites justify monitoring as code?

There is no fixed number. Repetition, change rate, compliance needs, and drift cost matter more than site count.

Should clients see the configuration repository?

Provide appropriate transparency without exposing other clients, internal routes, or sensitive metadata. Client-specific exports may be safer.

How do we handle an urgent manual change?

Allow a documented emergency path, then reconcile it into the desired state promptly.

Sources and further reading

Reviewed: 8 August 2026.

Next: Send Pingvera events to a help desk and manage multiple client websites.

Before building automation around Pingvera, confirm the current supported API, CLI, export, and webhook capabilities. Do not design against undocumented fields.

Originally published at pingvera.com.

Broken Links Across 50 Client Sites — What Should an Agency Fix First?

Pingvera.com — Thu, 27 Aug 2026 08:40:05 +0000

Broken Links Across 50 Client Sites: What Should an Agency Fix First?

A broken-link scan across 50 websites does not produce a to-do list. It produces a
pile.

Some links lose leads. Some break navigation. Some point to a harmless old source in a five-year-old
article. Some are blocked only for bots. If every 404 receives the same urgency, the agency either
wastes the week or ignores the report entirely.

The missing step is prioritization.

Not all broken links have equal impact

Rank a link by where it appears and what the visitor was trying to do.

Critical

checkout and payment;
contact, booking, or quote buttons;
login and account recovery;
primary navigation;
campaign landing pages;
legal or compliance documents required for a transaction.

High

product and service pages;
internal links from high-traffic pages;
download links promised in lead-generation content;
important support documentation;
canonical migration redirects.

Normal

old external citations;
low-traffic archive pages;
optional related-reading links;
third-party resources with a valid replacement.

The priority is business impact, not the raw count.

Internal and external links require different responses

Internal broken links

The agency usually controls the fix:

correct the URL;
restore the missing page;
add a relevant 301 redirect;
remove the link;
update a template or navigation component.

An internal broken link often points to a deployment, migration, CMS, or routing problem.

External broken links

The agency cannot restore the destination. Options are:

replace it with an authoritative alternative;
link to an archived copy where appropriate;
remove the citation;
keep the text without a link.

External sites may also block automated requests while working for browsers. Confirm before
creating a ticket.

The context an alert needs

"https://example.com returned 404" is incomplete.

Record:

source page;
anchor text;
destination;
internal or external;
HTTP status and redirect chain;
first and last detection;
number of pages containing the link;
whether the source is a critical page;
confirmation result.

One broken URL repeated in a global footer should become one issue with many occurrences, not 500
tickets.

A practical scoring model

Use a simple impact score:

The numbers are less important than consistency. The queue should put the business-critical
failures first.

Scan frequency

Use different schedules:

critical navigation and conversion links: after deployments and daily;
core content: weekly;
deep archives and external citations: monthly;
full portfolio scan: before quarterly reviews or migrations.

Scanning every URL every minute is wasteful and noisy. Broken-link monitoring is a coverage
problem, not an uptime frequency contest.

Common false positives

403 or 429 responses caused by bot protection;
temporary vendor outages;
links requiring authentication;
mailto: and tel: schemes treated as HTTP;
JavaScript navigation missed by a simple crawler;
relative URLs resolved against the wrong base;
intentionally removed campaign pages;
external sites blocking specific regions.

Confirm from another probe or a browser-like request before escalating.

Turn scan output into agency work

Deduplicate by destination and root cause.
Assign business impact.
Group template-wide occurrences.
Confirm high-priority failures.
Create one owner per issue.
Fix or redirect internal links.
Replace or remove external links.
Rescan the affected pages.
Add the completed work to the client report.

This is where monitoring becomes visible value:

Fixed three conversion-path links after a content migration and restored the quote flow
before the campaign launched.

Free first check

For an individual site, start with the
Pingvera broken-link checker. For an agency
portfolio, move from a one-time scan to scheduled monitoring with history, confirmation, ownership,
and client reporting.

Frequently asked questions

Do broken links directly hurt rankings?

The impact depends on context. Focus first on user experience, crawlability, internal
navigation, and lost conversion paths rather than treating every 404 as an SEO
emergency.

Should every removed page redirect to the homepage?

No. Redirect to a genuinely relevant replacement. If none exists, a correct 404 or 410 can be
better than a misleading redirect.

How should an agency report broken-link work?

Summarize affected business paths, completed fixes, and remaining client decisions. Keep the
full URL list in the appendix.

Sources

Originally published at pingvera.com.

Blameless Postmortem Template for Web Agencies

Pingvera.com — Thu, 27 Aug 2026 08:40:04 +0000

Blameless Postmortem Template for Web Agencies

A blameless postmortem examines how the system, process, tooling, assumptions, and operating context combined to produce an incident. It assumes people acted reasonably with the information and incentives available at the time, while still assigning clear ownership for corrective work.

For a small web agency, the meeting can take 45–60 minutes and the document can be concise. The value comes from evidence, honest detection and response review, and a small set of completed actions—not from enterprise ceremony.

At a glance

Define postmortem triggers before incidents.
Stabilise service before starting analysis.
Name a facilitator and document owner.
Build the timeline from evidence, not memory.
Separate impact, trigger, mechanism, and contributing conditions.
Review detection, classification, communication, mitigation, and recovery.
Identify what helped as well as what failed.
Create a few specific actions with owners, dates, and verification.
share learning at the appropriate level.
review action completion until closed.

Blameless does not mean accountability-free

Blameless practice removes shame from the investigation. It does not remove:

responsibility for unsafe behaviour;
contractual or management decisions;
security, legal, or HR processes;
ownership of corrective actions;
consequences for deliberate policy violations.

Keep those processes separate from the technical learning session where appropriate. People will hide weak signals if the retrospective is designed as a trial.

Define postmortem triggers

Examples:

P1 and selected P2 incidents;
material customer-visible downtime or degradation;
data loss, corruption, duplication, or exposure risk;
emergency rollback, failover, or restore;
client discovered the problem before monitoring;
response or recovery exceeded an agreed threshold;
repeated or near-miss event;
any participant or client service owner requests one.

Google SRE lists user-visible impact, data loss, on-call intervention, long resolution, and monitoring failure among common postmortem triggers.

Prepare the session

Invite the people who understand the event and the owners able to change the system. Avoid turning the meeting into a large audience performance.

Bring:

client incident report or incident record;
monitoring and application evidence;
deployment and configuration history;
provider communication;
timeline of client/status updates;
previous related incidents and actions;
service map and ownership.

The facilitator should challenge unsupported statements and redirect personal blame into conditions and controls.

Copyable postmortem template

Blameless postmortem

Incident ID: [ID]
Service/client: [value]
Date: [UTC]
Facilitator: [role]
Document owner: [role]
Participants: [roles]

1. Summary

[What happened and how service recovered.]

2. Impact

Affected journeys/users/regions:
Impact window:
Data/integrity/security impact:
Measurement limitations:

3. Detection

First evidence:
Alert/notification:
Incident declaration:
What monitoring missed or detected well:

4. Timeline

UTC	Fact, decision, action, or communication	Evidence
[time]	[value]	[link]

5. Trigger and failure mechanism

Trigger: [initiating event]
Failure mechanism: [how impact was produced]

6. Contributing conditions

Technical:
Process:
Ownership/communication:
Testing/monitoring:
Workload/timing/provider:

7. What helped

[control, person, fallback, tool, or decision]

8. What made response harder

[condition and evidence]

9. Decision review

Which decisions were reasonable with information available?
Which information arrived too late?
Which authority or runbook was unclear?

10. Actions

Action	Prevent/Detect/Mitigate/Recover	Owner	Due	Verification	Priority
[value]	[type]	[role]	[date]	[test/evidence]	[value]

11. Learning to share

[Audience, redactions, and concise lesson.]

12. Action review

Next review: [date]
Close condition: [all critical actions verified / accepted risk]

Ask better questions
Replace:

“Who broke production?” with “What allowed one action to create this blast radius?”
“Why did they not follow the runbook?” with “Was the runbook findable, current, safe, and practised?”
“Why did monitoring fail?” with “Which user outcome was not represented by a signal?”
“Why was the client angry?” with “Which expectation or update cadence was unclear?”
“Why did rollback take so long?” with “Which dependency, access, data, or decision delayed rollback?”

Trigger, cause, and contributing conditions

Example:

Trigger: routine plugin deployment.
Failure mechanism: changed JavaScript prevented checkout submission.
Contributing conditions: no browser-level checkout smoke test; release during a campaign; monitor checked only server response; rollback approval contact was unavailable.

“Plugin update caused it” is too shallow to prevent recurrence.

Review all phases

Before the incident

What risk was known?
What controls existed?
Was the change reviewed and recoverable?

Detection and classification

Who noticed first?
Did severity reflect business impact?
Which signal was missing or noisy?

Response and communication

Were roles clear?
Did the team make multiple conflicting changes?
Were client updates factual and timely?

Recovery

Was mitigation reversible?
Did recovery include downstream systems and data?
Were temporary access and suppressions removed?

Choose actions by control type

Balance:

Prevent: safer configuration, staged rollout, least privilege.
Detect: journey check, reconciliation, improved alert.
Mitigate: feature flag, degraded mode, documented rollback.
Recover: tested backup, ownership, access, runbook.

Avoid making training the only action when the system can be made safer by design.

Example: repeated certificate incident

The agency initially writes, “The account manager forgot renewal.” The postmortem reveals that ownership existed only in a private calendar, the registrar account belonged to an old client employee, renewal email went to an unmonitored mailbox, and no independent expiry alert existed.

Actions become: transfer ownership, create a shared renewal record, add 60/30/14-day monitoring, and test the escalation contact. The lesson is systemic and verifiable.

Common mistakes

writing the postmortem before facts are stable;
allowing managers to search for a culprit;
reducing cause to the last human action;
ignoring what worked;
creating dozens of vague actions;
assigning every action to “the team”;
never reviewing completion;
publishing sensitive security or client information too broadly;
performing the ceremony but not changing the system.

FAQ

Should the client attend the postmortem?

Usually hold an internal learning session first. Invite the client when shared systems, decisions, or trust make joint learning useful. The client incident report remains a separate deliverable.

How soon should the postmortem happen?

After service and immediate evidence are stable, while memory and context remain available. Do not let a fixed deadline force an invented root cause.

Is “root cause” always singular?

No. Complex incidents commonly have multiple interacting contributing conditions. Use precise language rather than forcing one cause.

How many actions should a small agency create?

Prefer a few high-value, owned, testable actions. Capacity is part of reliability.

Sources and further reading

Reviewed: 8 August 2026.

Next: Managing 10, 50, and 100 client websites and website incident report template.

Pingvera data can show when an external symptom began, which checks failed, and when recovery stabilised. It cannot decide the organisational lessons; that remains the team's job.

Originally published at pingvera.com.