Prompt Library for Agencies. Copy, Paste, Answer.

Check every mail record for deinkunde.com and tell me what is missing. Specifically: MX, SPF, DMARC, and DKIM for the selectors default, google, k1, s1, selector1 and selector2.

Give me a table with record type, value found, verdict and finding. Sort the findings by how badly each one hurts deliverability. For every finding, write out the DNS record that needs to be set, ready to copy.

Run a technical inventory of deinkunde.com before we take this client over. Check: A and AAAA records, MX, nameservers, WHOIS including domain expiry, the TLS certificate with issuer and remaining validity, the HTTP response headers, the redirect chain from http://deinkunde.com, and the response time.

Write it up as a handover record: first the current state as bullets, then a list of what we should touch in week one, one sentence of reasoning each.

Here are our domains: deinkunde.com, shop.deinkunde.com, mail.deinkunde.com, client-two.example, client-three.example.

For each one, check the domain registration expiry and the remaining validity of the TLS certificate. Give me a table sorted by the tightest deadline: domain, registration expires, certificate expires, days left, issuer.

Flag anything under 30 days. For those, write a short client email each: what expires, what happens if nobody acts, what we recommend. Matter of fact, no alarm.

We moved the A records of deinkunde.com to the new IP 203.0.113.10. Check DNS propagation across all available resolvers and tell me which ones still serve the old value.

Give me the current TTL and estimate from it how much longer we should wait before shutting the old server down. Finish with the one line I post in the project channel to report status.

The client reports that email from deinkunde.com lands in spam. Work through it systematically: SPF, DKIM for the selectors default and google, DMARC, MX records. Resolve the MX hosts to IP addresses, check those against the common DNS blacklists, and verify the PTR record matches the mail server hostname.

Finish with one sentence naming the most likely cause. Then the remedies in the order I should work through them, with rough effort per step. If an IP is listed, write the delisting request as a ready paragraph.

Read the current DMARC record for deinkunde.com and explain in plain language what it does today. Check SPF and DKIM first, so we know whether tightening is safe.

Then draft a staged plan from p=none through p=quarantine to p=reject: per stage the exact record value, the recommended run time, and the signal that tells me I am clear to move on.

Audit the full HTTPS chain for deinkunde.com: the redirect path from http://deinkunde.com and from http://www.deinkunde.com, the TLS certificate with issuer, validity and covered hostnames, and the HSTS configuration.

Tell me whether every variant lands on the canonical HTTPS URL in exactly one hop. List every redundant redirect separately and tell me what it costs.

Fetch the HTTP response headers for https://deinkunde.com and rate them. Look specifically at Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and X-Frame-Options.

Give me a table with header, current value, verdict and recommended value. Sort by impact per effort and flag the three I should set first. For each of those, name the risk of setting it too strictly.

deinkunde.com is reportedly unreachable. Run first triage: pull the site status, measure the response time, check DNS resolution, test whether port 80 and 443 are reachable, and run a ping test.

Tell me first, in one sentence, whether this is DNS, network, server or application. Details after that. If the data does not support a clear call, say so instead of guessing.

deinkunde.com responds slowly. Narrow it down: measure the response time with its individual phases, check DNS resolution, run a ping test against the host, test port 443, and find the network operator, location and PTR record of the target IP.

Tell me which part of the chain eats the time: DNS resolution, connect, TLS handshake, or the application itself. Give the measured value and a realistic target per phase. Summarise in two sentences I can forward to the hosting provider as is.

List all my monitors and pull the incidents from the last seven days.

Give me a briefing in three blocks: first everything still open, second the clients with the most incidents this week, third a one-liner for everything that stayed quiet. Keep it under 200 words. I read this before the first coffee.

List all my monitors and group them by client.

Then show me where coverage is thin: clients with a single monitor, monitors currently paused or in maintenance, and clients where the website is watched but no mail service and no certificate.

Turn that into a task list sorted by client, one sentence each on what I should add and why it helps that client.

Pull the incidents from the last 24 hours and the current status of every affected monitor.

Write a shift handover for the on-call responder: what is open, what just closed and might come back, what was a one-off. Per item name the monitor, the client, the time and the state. Finish with one sentence: what should on-call watch tonight in particular?

Show me the last five incidents across my portfolio and the current status of the affected monitor.

From that, write a status update for the client: what happened, since when, what we are doing right now, when the next update comes. Calm tone, no blame, no speculation about root cause, 120 words maximum. Then the same message again as a two-line version for the phone.

Take the monitor with ID [ID] and pull the check history for [date] between 08:00 and 12:00.

Build a timeline from it: first failed check, confirmation from further locations, recovery, total duration. Add the affected check locations. Then draft a post-mortem with the sections Timeline, Impact, Cause and Actions. Leave Cause open if the data does not support one.

Pull the incidents from the last 30 days and isolate the short ones, under five minutes.

For the three most frequent monitors, pull the check history around those timestamps and look for a pattern: did several check locations see the failure, or always the same one? Does the time of day repeat? Does it coincide with a maintenance window?

Per monitor, tell me whether this looks like a real outage or like noise, and what I would change in the configuration. If the data does not support a call, say so.

Pull the uptime figures for monitor [ID] for day, month and year, plus the average response times and this month's incidents.

Translate the numbers into client language: what does 99.95 percent in a month mean in actual minutes? Write three paragraphs for the monthly report: result, how it sits in the yearly trend, what we are watching next month. No jargon without explanation, no sugar-coating.

We promised deinkunde.com 99.9 percent monthly uptime. Pull the actual figures for monitor [ID] and this month's incidents. Work out how much downtime the promise allowed and how much of it we used.

If we went over: write an honest explanation plus two concrete actions. If we stayed under: write the single sentence I use to place that in the meeting without bragging.

For every monitor belonging to deinkunde.com, pull the uptime figures and the incidents of the last three months.

Build the quarterly meeting document: a table with service, uptime, incident count and longest outage. Then three sentences on the trend against the previous quarter, and one paragraph on what we actually did this quarter, evidenced by the data.

Write it so I can drop it on a slide without reworking it.

Pull the incidents of the last 90 days for the monitors of deinkunde.com, plus the uptime figures across the year.

Find patterns: do incidents cluster at certain hours, around certain services, in certain weeks? Build the case for a wider scope of care from it: observation, consequence for the client, proposal. Exactly three points, each backed by a number. If the data shows no pattern, say so and propose nothing.